stable inclusion
from stable-v5.10.153
commit 3b250824b6d3f109c8c18652280f7120c3803545
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=3b250824b6d3f109c8c18652280f7120c3803545

--------------------------------

commit 34cd2db4 upstream.

Systems based on Alder Lake P see significant boot time delay if
boot firmware tries to control usb ports in unexpected link states.

This is seen with self-powered usb devices that survive in U3 link
suspended state over S5.

A more generic solution to power off ports at shutdown was attempted in
commit 83810f84 ("xhci: turn off port power in shutdown")
but it caused regression.

Add host specific XHCI_RESET_TO_DEFAULT quirk which will reset host and
ports back to default state in shutdown.

Cc: stable@vger.kernel.org
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20221024142720.4122053-3-mathias.nyman@intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>

Conflicts:
	drivers/usb/host/xhci.h

stable inclusion
from stable-v5.10.153
commit 63c7df3c818ef2a1b56977968adf1d37fe6e691b
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=63c7df3c818ef2a1b56977968adf1d37fe6e691b

--------------------------------

commit ce107713 upstream.

Originally the absence of the marvell,nand-keep-config property caused
the setup_data_interface function to be provided. However when
setup_data_interface was moved into nand_controller_ops the logic was
unintentionally inverted. Update the logic so that only if the
marvell,nand-keep-config property is present the bootloader NAND config
kept.

Cc: stable@vger.kernel.org
Fixes: 7a08dbae ("mtd: rawnand: Move ->setup_data_interface() to nand_controller_ops")
Signed-off-by: NTony O'Brien <tony.obrien@alliedtelesis.co.nz>
Signed-off-by: NChris Packham <chris.packham@alliedtelesis.co.nz>
Reviewed-by: NBoris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20220927024728.28447-1-chris.packham@alliedtelesis.co.nzSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>

stable inclusion
from stable-v5.10.153
commit 228101fc832f0330f266e1f4002bd969a3be7850
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=228101fc832f0330f266e1f4002bd969a3be7850

--------------------------------

commit 4f547472 upstream.

This appears to fix the error:
"xhci_hcd <address>; ERROR Transfer event TRB DMA ptr not part of
current TD ep_index 2 comp_code 13" that appear spuriously (or pretty
often) when using a r8152 USB3 ethernet adapter with integrated hub.

ASM1042 reports as a 0.96 controller, but appears to behave more like 1.0

Inspired by this email thread: https://markmail.org/thread/7vzqbe7t6du6qsw3

Cc: stable@vger.kernel.org
Signed-off-by: NJens Glathe <jens.glathe@oldschoolsolutions.biz>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20221024142720.4122053-2-mathias.nyman@intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>

stable inclusion
from stable-v5.10.153
commit 2bc4f99ee24391bc05f0f464c4414ab0ad7b4f74
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=2bc4f99ee24391bc05f0f464c4414ab0ad7b4f74

--------------------------------

commit fb8f60dd upstream.

When port is connected and then disconnected, the state stays as
configured. Which is incorrect as the port is no longer configured,
but in a not attached state.
Signed-off-by: NJustin Chen <justinpopo6@gmail.com>
Acked-by: NFlorian Fainelli <f.fainelli@gmail.com>
Fixes: efed421a ("usb: gadget: Add UDC driver for Broadcom USB3.0 device controller IP BDC")
Cc: stable <stable@kernel.org>
Link: https://lore.kernel.org/r/1664997235-18198-1-git-send-email-justinpopo6@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>

stable inclusion
from stable-v5.10.153
commit e440957f9c8bedae784f718c42207af222c25818
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=e440957f9c8bedae784f718c42207af222c25818

--------------------------------

commit 308c316d upstream.

The gadget driver may have a certain expectation of how the request
completion flow should be from to its configuration. Make sure the
controller driver respect that. That is, don't set IMI (Interrupt on
Missed Isoc) when usb_request->no_interrupt is set. Also, the driver
should only set IMI to the last TRB of a chain.

Fixes: 72246da4 ("usb: Introduce DesignWare USB3 DRD Driver")
Cc: stable@vger.kernel.org
Signed-off-by: NThinh Nguyen <Thinh.Nguyen@synopsys.com>
Reviewed-by: NJeff Vanhoof <jdv1029@gmail.com>
Tested-by: NJeff Vanhoof <jdv1029@gmail.com>
Link: https://lore.kernel.org/r/ced336c84434571340c07994e3667a0ee284fefe.1666735451.git.Thinh.Nguyen@synopsys.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>

stable inclusion
from stable-v5.10.153
commit fb074d622ccc7e3999cde47f18ea7f8970b09d11
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=fb074d622ccc7e3999cde47f18ea7f8970b09d11

--------------------------------

commit f78961f8 upstream.

When servicing a transfer completion event, the dwc3 driver will reclaim
TRBs of started requests up to the request associated with the interrupt
event. Currently we don't check for interrupt due to missed isoc, and
the driver may attempt to reclaim TRBs beyond the associated event. This
causes invalid memory access when the hardware still owns the TRB. If
there's a missed isoc TRB with IMI (interrupt on missed isoc), make sure
to stop servicing further.

Note that only the last TRB of chained TRBs has its status updated with
missed isoc.

Fixes: 72246da4 ("usb: Introduce DesignWare USB3 DRD Driver")
Cc: stable@vger.kernel.org
Reported-by: NJeff Vanhoof <jdv1029@gmail.com>
Reported-by: NDan Vacura <w36195@motorola.com>
Signed-off-by: NThinh Nguyen <Thinh.Nguyen@synopsys.com>
Reviewed-by: NJeff Vanhoof <jdv1029@gmail.com>
Tested-by: NJeff Vanhoof <jdv1029@gmail.com>
Link: https://lore.kernel.org/r/b29acbeab531b666095dfdafd8cb5c7654fbb3e1.1666735451.git.Thinh.Nguyen@synopsys.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>

stable inclusion
from stable-v5.10.153
commit c29fcef5791d4c2782696f5a59316b3d92248c57
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=c29fcef5791d4c2782696f5a59316b3d92248c57

--------------------------------

commit fc4ade55 upstream.

NVIDIA Jetson devices in Force Recovery mode (RCM) do not support
suspending, ie. flashing fails if the device has been suspended. The
devices are still visible in lsusb and seem to work otherwise, making
the issue hard to debug. This has been discovered in various forum
posts, eg. [1].

The patch has been tested on NVIDIA Jetson AGX Xavier, but I'm adding
all the Jetson models listed in [2] on the assumption that they all
behave similarly.

[1]: https://forums.developer.nvidia.com/t/flashing-not-working/72365
[2]: https://docs.nvidia.com/jetson/archives/l4t-archived/l4t-3271/index.html#page/Tegra%20Linux%20Driver%20Package%20Development%20Guide/quick_start.htmlSigned-off-by: NHannu Hartikainen <hannu@hrtk.in>
Cc: stable <stable@kernel.org>  # after 6.1-rc3
Link: https://lore.kernel.org/r/20220919171610.30484-1-hannu@hrtk.inSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>

stable inclusion
from stable-v5.10.153
commit ca1034bff85a0cde000038e5af72756994f31560
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=ca1034bff85a0cde000038e5af72756994f31560

--------------------------------

commit 2871edb3 upstream.

kvaser_usb uses completions to signal when a response event is received
for outgoing commands.

However, it uses init_completion() to reinitialize the start_comp and
stop_comp completions before sending the start/stop commands.

In case the device sends the corresponding response just before the
actual command is sent, complete() may be called concurrently with
init_completion() which is not safe.

This might be triggerable even with a properly functioning device by
stopping the interface (CMD_STOP_CHIP) just after it goes bus-off (which
also causes the driver to send CMD_STOP_CHIP when restart-ms is off),
but that was not tested.

Fix the issue by using reinit_completion() instead.

Fixes: 080f40a6 ("can: kvaser_usb: Add support for Kvaser CAN/USB devices")
Tested-by: NJimmy Assarsson <extja@kvaser.com>
Signed-off-by: NAnssi Hannula <anssi.hannula@bitwise.fi>
Signed-off-by: NJimmy Assarsson <extja@kvaser.com>
Link: https://lore.kernel.org/all/20221010185237.319219-2-extja@kvaser.com
Cc: stable@vger.kernel.org
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>

hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6WAZX

--------------------------------

When the number of cores is greater than the number of ECMDQs, the number
of ECMDQs occupied by each NUMA node is less than the number of cores of
the node. Therefore, the first smmu->nr_ecmdq cores do not cover all
ECMDQs.

For example:
 ---------------------------------------
|       Node0       |       Node1       |
|---------------------------------------|
|   0   1   2   3   |   4   5   6   7   |  CPU ID
|---------------------------------------|
|      0      1     |      2      3     |  ECMDQ ID
 ---------------------------------------

Fixes: 3965519b ("iommu/arm-smmu-v3: Add support for less than one ECMDQ per core")
Signed-off-by: NZhen Lei <thunder.leizhen@huawei.com>
Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

driver inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I76TVJ
CVE: NA

----------------------------------------------------------------------

The debugfs files 'dev_state' and 'dev_timeout' are added.

dev_state: if dev_timeout is set, dev_state indicates the status
of stopping the queue. 0 indicates that the queue is stopped
successfully. Other values indicate that the queue stops fail.
if dev_timeout is not set, the value of dev_state is 0;

dev_timeout: If the queue fails to stop, the queue is released
after waiting dev_timeout * 20ms.
Signed-off-by: NWeili Qian <qianweili@huawei.com>
Signed-off-by: NJiangshui Yang <yangjiangshui@h-partners.com>

driver inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I76WNL
CVE: NA

----------------------------------------------------------------------

DMA setup lock timeout protection is added when DMA setup frames are
received, it's a function outside the protocol and used to prevent SATA
disk I/Os from being delivered for a long time. The default value is 100ms,
it's too strict and easily triggered timeout when the disk is overloaded
or faulty. Based on the average I/O latency of 300 disks, we adjust the
value to 2.5s.
Signed-off-by: NXingui Yang <yangxingui@huawei.com>
Signed-off-by: NYihang Li <liyihang9@huawei.com>
Reviewed-by: NXiang Chen <chenxiang66@hisilicon.com>
Signed-off-by: Nxiabing <xiabing12@h-partners.com>

mainline inclusion
from mainline-v6.2-rc1
commit 4ef4f1a6
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I76WNL
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4ef4f1a6155571d3d53583a4e8e7ccbbec220b8a

----------------------------------------------------------------------

When an NCQ error occurs, the controller will abnormally complete the I/Os
that are newly delivered to disk, and bit8 in CQ dw3 will be set which
indicates that the SATA disk is in error state. The current processing flow
is to set ts->stat to SAS_OPEN_REJECT and then sas_ata_task_done() will set
FIS stat to ATA_ERR. After analyzing the I/O by ata_eh_analyze_tf(),
err_mask will set to AC_ERR_HSM. If media error occurs for four times
within 10 minutes and the chip rejects new I/Os for four times, NCQ will be
disabled due to excessive errors, which is undesirable.

Therefore, use sas_task_abort() to handle abnormally completed I/Os when
SATA disk is in error state, as these abnormally completed I/Os are already
processed by sas_ata_device_link_abort() and qc->flag are set to
ATA_QCFLAG_FAILED. If sas_task_abort() is used, qc->err_mask will not be
modified in EH. Unlike the current process flow, it will not increase the
count of ECAT_TOUT_HSM and not turn off NCQ. Like other I/Os on the disk
that do not have an error but do not return after the NCQ error, they are
retried after the EH.
Signed-off-by: NXingui Yang <yangxingui@huawei.com>
Signed-off-by: NJohn Garry <john.garry@huawei.com>
Link: https://lore.kernel.org/r/1665998435-199946-5-git-send-email-john.garry@huawei.comSigned-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Nxiabing <xiabing12@h-partners.com>

3snic inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I6TX4J
CVE: NA

 --------------------------------

The driver supports 3snic 3s9xx serial network cards (100GE (40GE
compatible)-3S930 and 25GE (10GE compatible)-3S910/3S920).

Feature:
1. Support single-root I/O virtualization (SR-IOV)
2. Support virtual machine multi queue (VMMQ)
3. Support receive side scaling (RSS)
4. Support physical function (PF) passthrough VMs
5. Support the PF promiscuous mode,unicast or multicast MAC filtering, and
   all multicast mode
6. Support IPv4/IPv6, checksum offload,TCP Segmentation Offload (TSO), and
   Large Receive Offload (LRO)
7. Support in-band one-click logs collection
8. Support loopback tests
9. Support port location indicators
Reviewed-by: NChen Mou <chenmou@3snic.com>
Reviewed-by: NWan Renyong <wanry@3snic.com>
Reviewed-by: NYang Gan <yanggan@3snic.com>
Reviewed-by: NWen Liang <wenliang@3snic.com>
Signed-off-by: NSteven Song <steven.song@3snic.com>

stable inclusion
from stable-v5.10.152
commit e2f9b62ead9a69f5f605bb8777be5c97f292972d
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I73HJ0

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=e2f9b62ead9a69f5f605bb8777be5c97f292972d

--------------------------------

commit 07d2872b upstream.

Some SD-cards from Sandisk that are SDA-6.0 compliant reports they supports
discard, while they actually don't. This might cause mk2fs to fail while
trying to format the card and revert it to a read-only mode.

To fix this problem, let's add a card quirk (MMC_QUIRK_BROKEN_SD_DISCARD)
to indicate that we shall fall-back to use the legacy erase command
instead.
Signed-off-by: NAvri Altman <avri.altman@wdc.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20220928095744.16455-1-avri.altman@wdc.com
[Ulf: Updated the commit message]
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>

stable inclusion
from stable-v5.10.152
commit 67dafece56b6e78ccf956064b50f08c80dd6134e
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I73HJ0

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=67dafece56b6e78ccf956064b50f08c80dd6134e

--------------------------------

commit 3dbc80a3 upstream.

This commit is very different from the upstream commit! It fixes the same
issue by adding more quirks, rather then the general fix from the 6.1
kernel, because the general fix from the 6.1 kernel is part of a larger
refactoring of the backlight code which is not suitable for the stable
series.

As described in "ACPI: video: Drop NL5x?U, PF4NU1F and PF5?U??
acpi_backlight=native quirks" (10212754) the upstream commit "ACPI:
video: Make backlight class device registration a separate step (v2)"
(3dbc80a3) makes these quirks unnecessary. However as mentioned in this
bugtracker ticket https://bugzilla.kernel.org/show_bug.cgi?id=215683#c17
the upstream fix is part of a larger patchset that is overall too complex
for stable.

The TongFang GKxNRxx, GMxNGxx, GMxZGxx, and GMxRGxx / TUXEDO
Stellaris/Polaris Gen 1-4, have the same problem as the Clevo NL5xRU and
NL5xNU / TUXEDO Aura 15 Gen1 and Gen2:
They have a working native and video interface for screen backlight.
However the default detection mechanism first registers the video interface
before unregistering it again and switching to the native interface during
boot. This results in a dangling SBIOS request for backlight change for
some reason, causing the backlight to switch to ~2% once per boot on the
first power cord connect or disconnect event. Setting the native interface
explicitly circumvents this buggy behaviour by avoiding the unregistering
process.
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NWerner Sembach <wse@tuxedocomputers.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>

stable inclusion
from stable-v5.10.152
commit dcaf6313202a02cee13302a04a9b0503352ddef2
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I73HJ0

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=dcaf6313202a02cee13302a04a9b0503352ddef2

--------------------------------

commit 365e1ece upstream.

During vm boot, there might be possibility that vf registration
call comes before the vf association from host to vm.

And this might break netvsc vf path, To prevent the same block
vf registration until vf bind message comes from host.

Cc: stable@vger.kernel.org
Fixes: 00d7ddba ("hv_netvsc: pair VF based on serial number")
Reviewed-by: NHaiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: NGaurav Kohli <gauravkohli@linux.microsoft.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>

stable inclusion
from stable-v5.10.152
commit 7fba4a389d070daf17e18c657c8e31f03cc2486b
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I73HJ0

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=7fba4a389d070daf17e18c657c8e31f03cc2486b

--------------------------------

[ Upstream commit b78870e7 ]

Ensure tegra_host member "curr_clk_rate" holds the actual clock rate
instead of requested clock rate for proper use during tuning correction
algorithm. Actual clk rate may not be the same as the requested clk
frequency depending on the parent clock source set. Tuning correction
algorithm depends on certain parameters which are sensitive to current
clk rate. If the host clk is selected instead of the actual clock rate,
tuning correction algorithm may end up applying invalid correction,
which could result in errors

Fixes: ea8fc595 ("mmc: tegra: update hw tuning process")
Signed-off-by: NAniruddha TVS Rao <anrao@nvidia.com>
Signed-off-by: NPrathamesh Shete <pshete@nvidia.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Acked-by: NThierry Reding <treding@nvidia.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20221006130622.22900-4-pshete@nvidia.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>

stable inclusion
from stable-v5.10.152
commit 3c6a888e352283a14f37b9b433cd598a1a3a7dd0
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I73HJ0

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=3c6a888e352283a14f37b9b433cd598a1a3a7dd0

--------------------------------

[ Upstream commit 5c13a4a0 ]

Prior to this commit, the gntdev driver code did not handle the
following scenario correctly with paravirtualized (PV) Xen domains:

* User process sets up a gntdev mapping composed of two grant mappings
  (i.e., two pages shared by another Xen domain).
* User process munmap()s one of the pages.
* User process munmap()s the remaining page.
* User process exits.

In the scenario above, the user process would cause the kernel to log
the following messages in dmesg for the first munmap(), and the second
munmap() call would result in similar log messages:

  BUG: Bad page map in process doublemap.test  pte:... pmd:...
  page:0000000057c97bff refcount:1 mapcount:-1 \
    mapping:0000000000000000 index:0x0 pfn:...
  ...
  page dumped because: bad pte
  ...
  file:gntdev fault:0x0 mmap:gntdev_mmap [xen_gntdev] readpage:0x0
  ...
  Call Trace:
   <TASK>
   dump_stack_lvl+0x46/0x5e
   print_bad_pte.cold+0x66/0xb6
   unmap_page_range+0x7e5/0xdc0
   unmap_vmas+0x78/0xf0
   unmap_region+0xa8/0x110
   __do_munmap+0x1ea/0x4e0
   __vm_munmap+0x75/0x120
   __x64_sys_munmap+0x28/0x40
   do_syscall_64+0x38/0x90
   entry_SYSCALL_64_after_hwframe+0x61/0xcb
   ...

For each munmap() call, the Xen hypervisor (if built with CONFIG_DEBUG)
would print out the following and trigger a general protection fault in
the affected Xen PV domain:

  (XEN) d0v... Attempt to implicitly unmap d0's grant PTE ...
  (XEN) d0v... Attempt to implicitly unmap d0's grant PTE ...

As of this writing, gntdev_grant_map structure's vma field (referred to
as map->vma below) is mainly used for checking the start and end
addresses of mappings. However, with split VMAs, these may change, and
there could be more than one VMA associated with a gntdev mapping.
Hence, remove the use of map->vma and rely on map->pages_vm_start for
the original start address and on (map->count << PAGE_SHIFT) for the
original mapping size. Let the invalidate() and find_special_page()
hooks use these.

Also, given that there can be multiple VMAs associated with a gntdev
mapping, move the "mmu_interval_notifier_remove(&map->notifier)" call to
the end of gntdev_put_map, so that the MMU notifier is only removed
after the closing of the last remaining VMA.

Finally, use an atomic to prevent inadvertent gntdev mapping re-use,
instead of using the map->live_grants atomic counter and/or the map->vma
pointer (the latter of which is now removed). This prevents the
userspace from mmap()'ing (with MAP_FIXED) a gntdev mapping over the
same address range as a previously set up gntdev mapping. This scenario
can be summarized with the following call-trace, which was valid prior
to this commit:

  mmap
    gntdev_mmap
  mmap (repeat mmap with MAP_FIXED over the same address range)
    gntdev_invalidate
      unmap_grant_pages (sets 'being_removed' entries to true)
        gnttab_unmap_refs_async
    unmap_single_vma
    gntdev_mmap (maps the shared pages again)
  munmap
    gntdev_invalidate
      unmap_grant_pages
        (no-op because 'being_removed' entries are true)
    unmap_single_vma (For PV domains, Xen reports that a granted page
      is being unmapped and triggers a general protection fault in the
      affected domain, if Xen was built with CONFIG_DEBUG)

The fix for this last scenario could be worth its own commit, but we
opted for a single commit, because removing the gntdev_grant_map
structure's vma field requires guarding the entry to gntdev_mmap(), and
the live_grants atomic counter is not sufficient on its own to prevent
the mmap() over a pre-existing mapping.

Link: https://github.com/QubesOS/qubes-issues/issues/7631
Fixes: ab31523c ("xen/gntdev: allow usermode to map granted pages")
Cc: stable@vger.kernel.org
Signed-off-by: NM. Vefa Bicakci <m.v.b@runbox.com>
Reviewed-by: NJuergen Gross <jgross@suse.com>
Link: https://lore.kernel.org/r/20221002222006.2077-3-m.v.b@runbox.comSigned-off-by: NJuergen Gross <jgross@suse.com>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>

stable inclusion
from stable-v5.10.152
commit 5232411f37d79654db574ff7357c5acc4620f173
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I73HJ0

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=5232411f37d79654db574ff7357c5acc4620f173

--------------------------------

[ Upstream commit 30dcc56b ]

XENFEAT_gnttab_map_avail_bits is always set in Xen 4.0 and newer.
Remove coding assuming it might be zero.
Signed-off-by: NJuergen Gross <jgross@suse.com>
Acked-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: NBoris Ostrovsky <boris.ostrovsky@oracle.com>
Link: https://lore.kernel.org/r/20210730071804.4302-4-jgross@suse.comSigned-off-by: NJuergen Gross <jgross@suse.com>
Stable-dep-of: 5c13a4a0 ("xen/gntdev: Accommodate VMA splitting")
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>

stable inclusion
from stable-v5.10.152
commit 4e3a15ca24b33961da73d54ebfd4a3fd8bcc7bd7
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I73HJ0

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=4e3a15ca24b33961da73d54ebfd4a3fd8bcc7bd7

--------------------------------

[ Upstream commit 26696d46 ]

Driver registration fails on SOC imx8mn as its supplier, the clock
control module, is probed later than subsys initcall level. This driver
uses platform_driver_probe which is not compatible with deferred probing
and won't be probed again later if probe function fails due to clock not
being available at that time.

This patch replaces the use of platform_driver_probe with
platform_driver_register which will allow probing the driver later again
when the clock control module will be available.

The __init annotation has been dropped because it is not compatible with
deferred probing. The code is not executed once and its memory cannot be
freed.

Fixes: a580b8c5 ("dmaengine: mxs-dma: add dma support for i.MX23/28")
Co-developed-by: NMichael Trimarchi <michael@amarulasolutions.com>
Signed-off-by: NMichael Trimarchi <michael@amarulasolutions.com>
Signed-off-by: NDario Binacchi <dario.binacchi@amarulasolutions.com>
Acked-by: NSascha Hauer <s.hauer@pengutronix.de>
Cc: stable@vger.kernel.org

Link: https://lore.kernel.org/r/20220921170556.1055962-1-dario.binacchi@amarulasolutions.comSigned-off-by: NVinod Koul <vkoul@kernel.org>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>

stable inclusion
from stable-v5.10.152
commit 1da5d249704666fe8d3b1cb531d73fb6c621d84f
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I73HJ0

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=1da5d249704666fe8d3b1cb531d73fb6c621d84f

--------------------------------

[ Upstream commit cc2afb0d ]

The mxs-dma driver is only used by DT platforms and the .id_table
is unused.

Get rid of it to simplify the code.
Signed-off-by: NFabio Estevam <festevam@gmail.com>
Link: https://lore.kernel.org/r/20201123193051.17285-1-festevam@gmail.comSigned-off-by: NVinod Koul <vkoul@kernel.org>
Stable-dep-of: 26696d46 ("dmaengine: mxs: use platform_driver_register")
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>

stable inclusion
from stable-v5.10.152
commit 1414e9bf3c307759347e6c91ed1143065ee86402
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I73HJ0

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=1414e9bf3c307759347e6c91ed1143065ee86402

--------------------------------

[ Upstream commit 4656b3a2 ]

Make virtio_gpu_plane_cleanup_fb() to clean the state which DRM core
wants to clean up and not the current plane's state. Normally the older
atomic state is cleaned up, but the newer state could also be cleaned up
in case of aborted commits.

Cc: stable@vger.kernel.org
Signed-off-by: NDmitry Osipenko <dmitry.osipenko@collabora.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20220630200726.1884320-6-dmitry.osipenko@collabora.comSigned-off-by: NGerd Hoffmann <kraxel@redhat.com>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>

stable inclusion
from stable-v5.10.152
commit d74196bb278b8f8af88e16bd595997dfa3d6fdb0
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I73HJ0

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=d74196bb278b8f8af88e16bd595997dfa3d6fdb0

--------------------------------

[ Upstream commit 620bf9f9 ]

A splat from kmem_cache_destroy() was seen with a kernel prior to
commit ee2653bb ("iommu/vt-d: Remove domain and devinfo mempool")
when there was a failure in init_dmars(), because the iommu_domain
cache still had objects. While the mempool code is now gone, there
still is a leak of the si_domain memory if init_dmars() fails. So
clean up si_domain in the init_dmars() error path.

Cc: Lu Baolu <baolu.lu@linux.intel.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Will Deacon <will@kernel.org>
Cc: Robin Murphy <robin.murphy@arm.com>
Fixes: 86080ccc ("iommu/vt-d: Allocate si_domain in init_dmars()")
Signed-off-by: NJerry Snitselaar <jsnitsel@redhat.com>
Link: https://lore.kernel.org/r/20221010144842.308890-1-jsnitsel@redhat.comSigned-off-by: NLu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: NJoerg Roedel <jroedel@suse.de>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>

stable inclusion
from stable-v5.10.152
commit 35c92435be76acdd544c834ae734b88d08e91e0e
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I73HJ0

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=35c92435be76acdd544c834ae734b88d08e91e0e

--------------------------------

[ Upstream commit 7f378c03 ]

If the cable is disconnected the PHY seems to toggle between MDI and
MDI-X modes. With the MDI crossover status interrupt active this causes
roughly 10 interrupts per second.

As the crossover status isn't checked by the driver, the interrupt can
be disabled to reduce the interrupt load.

Fixes: 87461f7a ("net: phy: DP83822 initial driver submission")
Signed-off-by: NFelix Riemann <felix.riemann@sma.de>
Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
Link: https://lore.kernel.org/r/20221018104755.30025-1-svc.sw.rte.linux@sma.deSigned-off-by: NJakub Kicinski <kuba@kernel.org>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>

stable inclusion
from stable-v5.10.152
commit 2974f3b330ef25f5d34a4948d04290c2cd7802cf
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I73HJ0

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=2974f3b330ef25f5d34a4948d04290c2cd7802cf

--------------------------------

[ Upstream commit ff2f5ec5 ]

Inject fault while probing module, if device_register() fails,
but the refcount of kobject is not decreased to 0, the name
allocated in dev_set_name() is leaked. Fix this by calling
put_device(), so that name can be freed in callback function
kobject_cleanup().

unreferenced object 0xffff00c01aba2100 (size 128):
  comm "systemd-udevd", pid 1259, jiffies 4294903284 (age 294.152s)
  hex dump (first 32 bytes):
    68 6e 61 65 30 00 00 00 18 21 ba 1a c0 00 ff ff  hnae0....!......
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [<0000000034783f26>] slab_post_alloc_hook+0xa0/0x3e0
    [<00000000748188f2>] __kmem_cache_alloc_node+0x164/0x2b0
    [<00000000ab0743e8>] __kmalloc_node_track_caller+0x6c/0x390
    [<000000006c0ffb13>] kvasprintf+0x8c/0x118
    [<00000000fa27bfe1>] kvasprintf_const+0x60/0xc8
    [<0000000083e10ed7>] kobject_set_name_vargs+0x3c/0xc0
    [<000000000b87affc>] dev_set_name+0x7c/0xa0
    [<000000003fd8fe26>] hnae_ae_register+0xcc/0x190 [hnae]
    [<00000000fe97edc9>] hns_dsaf_ae_init+0x9c/0x108 [hns_dsaf]
    [<00000000c36ff1eb>] hns_dsaf_probe+0x548/0x748 [hns_dsaf]

Fixes: 6fe6611f ("net: add Hisilicon Network Subsystem hnae framework support")
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Reviewed-by: NLeon Romanovsky <leonro@nvidia.com>
Link: https://lore.kernel.org/r/20221018122451.1749171-1-yangyingliang@huawei.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>

stable inclusion
from stable-v5.10.152
commit 3032e316e0a9a04b9cc3ca73ff22c4d546aee243
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I73HJ0

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=3032e316e0a9a04b9cc3ca73ff22c4d546aee243

--------------------------------

[ Upstream commit c2bf23e4 ]

Filters on different vports are qualified by different implicit MACs and/or
VLANs, so shouldn't be considered equal even if their other match fields
are identical.

Fixes: 7c460d9b ("sfc: Extend and abstract efx_filter_spec to cover Huntington/EF10")
Co-developed-by: NEdward Cree <ecree.xilinx@gmail.com>
Signed-off-by: NEdward Cree <ecree.xilinx@gmail.com>
Signed-off-by: NPieter Jansen van Vuuren <pieter.jansen-van-vuuren@amd.com>
Reviewed-by: NMartin Habets <habetsm.xilinx@gmail.com>
Link: https://lore.kernel.org/r/20221018092841.32206-1-pieter.jansen-van-vuuren@amd.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>

stable inclusion
from stable-v5.10.152
commit 2008ad08a2aee0aa8d6201c509bf6546f0df1183
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I73HJ0

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=2008ad08a2aee0aa8d6201c509bf6546f0df1183

--------------------------------

[ Upstream commit c94b7f9b ]

Recent commit 52fde2c0 ("nvme: set dma alignment to dword") has
caused a regression on our platform.

It turned out that the nvme_get_log() method invocation caused the
nvme_hwmon_data structure instance corruption.  In particular the
nvme_hwmon_data.ctrl pointer was overwritten either with zeros or with
garbage.  After some research we discovered that the problem happened
even before the actual NVME DMA execution, but during the buffer mapping.
Since our platform is DMA-noncoherent, the mapping implied the cache-line
invalidations or write-backs depending on the DMA-direction parameter.
In case of the NVME SMART log getting the DMA was performed
from-device-to-memory, thus the cache-invalidation was activated during
the buffer mapping.  Since the log-buffer isn't cache-line aligned, the
cache-invalidation caused the neighbour data to be discarded.  The
neighbouring data turned to be the data surrounding the buffer in the
framework of the nvme_hwmon_data structure.

In order to fix that we need to make sure that the whole log-buffer is
defined within the cache-line-aligned memory region so the
cache-invalidation procedure wouldn't involve the adjacent data. One of
the option to guarantee that is to kmalloc the DMA-buffer [1]. Seeing the
rest of the NVME core driver prefer that method it has been chosen to fix
this problem too.

Note after a deeper researches we found out that the denoted commit wasn't
a root cause of the problem. It just revealed the invalidity by activating
the DMA-based NVME SMART log getting performed in the framework of the
NVME hwmon driver. The problem was here since the initial commit of the
driver.

[1] Documentation/core-api/dma-api-howto.rst

Fixes: 400b6a7b ("nvme: Add hardware monitoring support")
Signed-off-by: NSerge Semin <Sergey.Semin@baikalelectronics.ru>
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>

stable inclusion
from stable-v5.10.152
commit 770b7e3a2c1f32e82c5c9143d0a3670e9ea95a5f
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I73HJ0

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=770b7e3a2c1f32e82c5c9143d0a3670e9ea95a5f

--------------------------------

[ Upstream commit 6b8cf940 ]

An NVMe controller works perfectly fine even when the hwmon
initialization fails.  Stop returning errors that do not come from a
controller reset from nvme_hwmon_init to handle this case consistently.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
Reviewed-by: NSerge Semin <fancer.lancer@gmail.com>
Stable-dep-of: c94b7f9b ("nvme-hwmon: kmalloc the NVME SMART log buffer")
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>

stable inclusion
from stable-v5.10.152
commit 67106ac27243313beb58097449555f92ea5947ec
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I73HJ0

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=67106ac27243313beb58097449555f92ea5947ec

--------------------------------

[ Upstream commit 78570f88 ]

The hwmon pointer wont be NULL if the registration fails. Though the
exit code path will assign it to ctrl->hwmon_device. Later
nvme_hwmon_exit() will try to free the invalid pointer. Avoid this by
returning the error code from hwmon_device_register_with_info().

Fixes: ed7770f6 ("nvme/hwmon: rework to avoid devm allocation")
Signed-off-by: NDaniel Wagner <dwagner@suse.de>
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Stable-dep-of: c94b7f9b ("nvme-hwmon: kmalloc the NVME SMART log buffer")
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>

stable inclusion
from stable-v5.10.152
commit bc17f727b005921fc3b8651daefa053200c57cf0
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I73HJ0

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=bc17f727b005921fc3b8651daefa053200c57cf0

--------------------------------

[ Upstream commit ed7770f6 ]

The original design to use device-managed resource allocation
doesn't really work as the NVMe controller has a vastly different
lifetime than the hwmon sysfs attributes, causing warning about
duplicate sysfs entries upon reconnection.
This patch reworks the hwmon allocation to avoid device-managed
resource allocation, and uses the NVMe controller as parent for
the sysfs attributes.

Cc: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: NHannes Reinecke <hare@suse.de>
Tested-by: NEnzo Matsumiya <ematsumiya@suse.de>
Tested-by: NDaniel Wagner <dwagner@suse.de>
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Stable-dep-of: c94b7f9b ("nvme-hwmon: kmalloc the NVME SMART log buffer")
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>

stable inclusion
from stable-v5.10.152
commit 191d71c6357ef6e64b07e37b1e28c44480526d5a
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I73HJ0

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=191d71c6357ef6e64b07e37b1e28c44480526d5a

--------------------------------

[ Upstream commit aa1d7e12 ]

It's possible that the driver will dereference a qcq that doesn't exist
when calling ionic_reconfigure_queues(), which causes a page fault BUG.

If a reduction in the number of queues is followed by a different
reconfig such as changing the ring size, the driver can hit a NULL
pointer when trying to clean up non-existent queues.

Fix this by checking to make sure both the qcqs array and qcq entry
exists bofore trying to use and free the entry.

Fixes: 101b40a0 ("ionic: change queue count with no reset")
Signed-off-by: NBrett Creeley <brett@pensando.io>
Signed-off-by: NShannon Nelson <snelson@pensando.io>
Link: https://lore.kernel.org/r/20221017233123.15869-1-snelson@pensando.ioSigned-off-by: NJakub Kicinski <kuba@kernel.org>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>

stable inclusion
from stable-v5.10.152
commit 05cc22c0085e18627df110facd731359b83be7ef
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I73HJ0

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=05cc22c0085e18627df110facd731359b83be7ef

--------------------------------

[ Upstream commit 0c9efbd5 ]

When RX strap in HW is not set to MODE 3 or 4, bit 7 and 8 in CF4
register should be set. The former is already handled in
dp83867_config_init; add the latter in SGMII specific initialization.

Fixes: 2a10154a ("net: phy: dp83867: Add TI dp83867 phy")
Signed-off-by: NHarini Katakam <harini.katakam@amd.com>
Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>

stable inclusion
from stable-v5.10.152
commit c8310a99e7e4ad658aa5160fe817533d0d7069fe
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I73HJ0

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=c8310a99e7e4ad658aa5160fe817533d0d7069fe

--------------------------------

[ Upstream commit a8aed7b3 ]

Changing a VF's mac address through the VF (rather than via the PF)
fails with EPERM because the latter part of efx_ef10_set_mac_address
attempts to change the vport mac address list as the VF.
Even with this fixed it still fails with EBUSY because the vadaptor
is still assigned on the VF - the vadaptor reassignment must be within
a section where the VF has torn down its state.

A major reason this has broken is because we have two functions that
ostensibly do the same thing - have a PF and VF cooperate to change a
VF mac address. Rather than do this, if we are changing the mac of a VF
that has a link to the PF in the same VM then simply call
sriov_set_vf_mac instead, which is a proven working function that does
that.

If there is no PF available, or that fails non-fatally, then attempt to
change the VF's mac address as we would a PF, without updating the PF's
data.

Test case:
Create a VF:
  echo 1 > /sys/class/net/<if>/device/sriov_numvfs
Set the mac address of the VF directly:
  ip link set <vf> addr 00:11:22:33:44:55
Set the MAC address of the VF via the PF:
  ip link set <pf> vf 0 mac 00:11:22:33:44:66
Without this patch the last command will fail with ENOENT.
Signed-off-by: NJonathan Cooper <jonathan.s.cooper@amd.com>
Reported-by: NÍñigo Huguet <ihuguet@redhat.com>
Fixes: 910c8789 ("set the MAC address using MC_CMD_VADAPTOR_SET_MAC")
Acked-by: NEdward Cree <ecree.xilinx@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>

stable inclusion
from stable-v5.10.152
commit 39d10f0dfb7201cbd722706e0c428e4f7d89281f
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I73HJ0

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=39d10f0dfb7201cbd722706e0c428e4f7d89281f

--------------------------------

[ Upstream commit bb5f0c85 ]

Under certain conditions the Magic Trackpad can group 2 reports in a
single packet. The packet is split and the raw event function is
invoked recursively for each part.

However, after processing each part, the BTN_MOUSE status is updated,
sending multiple click events. [1]

Return after processing double reports to avoid this issue.

Link: https://gitlab.freedesktop.org/libinput/libinput/-/issues/811  # [1]
Fixes: a462230e ("HID: magicmouse: enable Magic Trackpad support")
Reported-by: NNulo <git@nulo.in>
Signed-off-by: NJosé Expósito <jose.exposito89@gmail.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Link: https://lore.kernel.org/r/20221009182747.90730-1-jose.exposito89@gmail.comSigned-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>

stable inclusion
from stable-v5.10.152
commit ed5baf3d0a33caaca4cd4073ebb0854cc77a616d
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I73HJ0

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=ed5baf3d0a33caaca4cd4073ebb0854cc77a616d

--------------------------------

[ Upstream commit aae425ef ]

During reallocation of RX buffers, new DMA mappings are created for
those buffers.

steps for reproduction:
while :
do
for ((i=0; i<=8160; i=i+32))
do
ethtool -G enp130s0f0 rx $i tx $i
sleep 0.5
ethtool -g enp130s0f0
done
done

This resulted in crash:
i40e 0000:01:00.1: Unable to allocate memory for the Rx descriptor ring, size=65536
Driver BUG
WARNING: CPU: 0 PID: 4300 at net/core/xdp.c:141 xdp_rxq_info_unreg+0x43/0x50
Call Trace:
i40e_free_rx_resources+0x70/0x80 [i40e]
i40e_set_ringparam+0x27c/0x800 [i40e]
ethnl_set_rings+0x1b2/0x290
genl_family_rcv_msg_doit.isra.15+0x10f/0x150
genl_family_rcv_msg+0xb3/0x160
? rings_fill_reply+0x1a0/0x1a0
genl_rcv_msg+0x47/0x90
? genl_family_rcv_msg+0x160/0x160
netlink_rcv_skb+0x4c/0x120
genl_rcv+0x24/0x40
netlink_unicast+0x196/0x230
netlink_sendmsg+0x204/0x3d0
sock_sendmsg+0x4c/0x50
__sys_sendto+0xee/0x160
? handle_mm_fault+0xbe/0x1e0
? syscall_trace_enter+0x1d3/0x2c0
__x64_sys_sendto+0x24/0x30
do_syscall_64+0x5b/0x1a0
entry_SYSCALL_64_after_hwframe+0x65/0xca
RIP: 0033:0x7f5eac8b035b
Missing register, driver bug
WARNING: CPU: 0 PID: 4300 at net/core/xdp.c:119 xdp_rxq_info_unreg_mem_model+0x69/0x140
Call Trace:
xdp_rxq_info_unreg+0x1e/0x50
i40e_free_rx_resources+0x70/0x80 [i40e]
i40e_set_ringparam+0x27c/0x800 [i40e]
ethnl_set_rings+0x1b2/0x290
genl_family_rcv_msg_doit.isra.15+0x10f/0x150
genl_family_rcv_msg+0xb3/0x160
? rings_fill_reply+0x1a0/0x1a0
genl_rcv_msg+0x47/0x90
? genl_family_rcv_msg+0x160/0x160
netlink_rcv_skb+0x4c/0x120
genl_rcv+0x24/0x40
netlink_unicast+0x196/0x230
netlink_sendmsg+0x204/0x3d0
sock_sendmsg+0x4c/0x50
__sys_sendto+0xee/0x160
? handle_mm_fault+0xbe/0x1e0
? syscall_trace_enter+0x1d3/0x2c0
__x64_sys_sendto+0x24/0x30
do_syscall_64+0x5b/0x1a0
entry_SYSCALL_64_after_hwframe+0x65/0xca
RIP: 0033:0x7f5eac8b035b

This was caused because of new buffers with different RX ring count should
substitute older ones, but those buffers were freed in
i40e_configure_rx_ring and reallocated again with i40e_alloc_rx_bi,
thus kfree on rx_bi caused leak of already mapped DMA.

Fix this by reallocating ZC with rx_bi_zc struct when BPF program loads. Additionally
reallocate back to rx_bi when BPF program unloads.

If BPF program is loaded/unloaded and XSK pools are created, reallocate
RX queues accordingly in XSP_SETUP_XSK_POOL handler.

Fixes: be1222b5 ("i40e: Separate kernel allocated rx_bi rings from AF_XDP rings")
Signed-off-by: NJan Sokolowski <jan.sokolowski@intel.com>
Signed-off-by: NMateusz Palczewski <mateusz.palczewski@intel.com>
Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
Tested-by: Chandan <chandanx.rout@intel.com> (A Contingent Worker at Intel)
Tested-by: Gurucharan <gurucharanx.g@intel.com> (A Contingent worker at Intel)
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>

stable inclusion
from stable-v5.10.152
commit fc8c6b8bb294b7c1b2853808648e7a2cec392b61
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I73HJ0

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=fc8c6b8bb294b7c1b2853808648e7a2cec392b61

--------------------------------

[ Upstream commit f6ec01da ]

If there is no user space consumer of extlog_mem trace records, then
Linux properly handles multiple error records in an ELOG block

	extlog_print()
	  print_extlog_rcd()
	    __print_extlog_rcd()
	      cper_estatus_print()
		apei_estatus_for_each_section()

But the other code path hard codes looking for a single record to
output a trace record.

Fix by using the same apei_estatus_for_each_section() iterator
to step over all records.

Fixes: 2dfb7d51 ("trace, RAS: Add eMCA trace event interface")
Signed-off-by: NTony Luck <tony.luck@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>

stable inclusion
from stable-v5.10.152
commit cc841a8a704c1de58491b8f158d661c065cfb831
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I73HJ0

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=cc841a8a704c1de58491b8f158d661c065cfb831

--------------------------------

commit 1bd3a383 upstream.

The Lenovo OneLink+ Dock contains an RTL8153 controller that behaves as
a broken CDC device by default. Add the custom Lenovo PID to the r8152
driver to support it properly.

Also, systems compatible with this dock provide a BIOS option to enable
MAC address passthrough (as per Lenovo document "ThinkPad Docking
Solutions 2017"). Add the custom PID to the MAC passthrough list too.

Tested on a ThinkPad 13 1st gen with the expected results:

passthrough disabled: Invalid header when reading pass-thru MAC addr
passthrough enabled:  Using pass-thru MAC addr XX:XX:XX:XX:XX:XX
Signed-off-by: NJean-Francois Le Fillatre <jflf_kernel@gmx.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>

stable inclusion
from stable-v5.10.152
commit ab6aaa821024978b203b3e4cc431ba61ea495c21
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I73HJ0

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=ab6aaa821024978b203b3e4cc431ba61ea495c21

--------------------------------

commit 06a2da34 upstream.

Debugging the decoder on msm8916 I noticed the vdec probe was crashing if
the fmt pointer was NULL.

A similar fix from Colin Ian King found by Coverity was implemented for the
encoder. Implement the same fix on the decoder.

Fixes: 7472c1c6 ("[media] media: venus: vdec: add video decoder files")
Cc: stable@vger.kernel.org  # v4.13+
Signed-off-by: NBryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: NStanimir Varbanov <stanimir.varbanov@linaro.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>

stable inclusion
from stable-v5.10.152
commit bce5808fc95dbc8604e55a311881f04c5a9a37d6
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I73HJ0

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=bce5808fc95dbc8604e55a311881f04c5a9a37d6

--------------------------------

commit 20b794dd upstream.

By rounding down, the actual timeout can be lower than requested. As a
result, long spaces just below the requested timeout can be incorrectly
reported as timeout and truncated.

Fixes: 877f1a7c ("media: rc: mceusb: allow the timeout to be configurable")
Cc: stable@vger.kernel.org
Signed-off-by: NSean Young <sean@mess.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>

stable inclusion
from stable-v5.10.152
commit e55feb31df3fc78b880d6e9d4b5853f05c974833
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I73HJ0

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=e55feb31df3fc78b880d6e9d4b5853f05c974833

--------------------------------

commit 9f42cf54 upstream.

If for some reason the speedbin length is incorrect, then there is a
memory leak in the error path because we never free the speedbin buffer.
This commit fixes the error path to always free the speedbin buffer.

Cc: v5.7+ <stable@vger.kernel.org> # v5.7+
Fixes: a8811ec7 ("cpufreq: qcom: Add support for krait based socs")
Signed-off-by: NFabien Parent <fabien.parent@linaro.org>
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>