lp:~timg-tpi/ubuntu/+source/linux/+git/focal

Author: Dexuan Cui
Author Date: 2023-04-20 01:43:19 UTC

UBUNTU: SAUCE: PCI: hv: Add a per-bus mutex state_lock

BugLink: https://bugs.launchpad.net/bugs/2023594

In the case of fast device addition/removal, it's possible that
hv_eject_device_work() can start to run before create_root_hv_pci_bus()
starts to run; as a result, the pci_get_domain_bus_and_slot() in
hv_eject_device_work() can return a 'pdev' of NULL, and
hv_eject_device_work() can remove the 'hpdev', and immediately send a
message PCI_EJECTION_COMPLETE to the host, and the host immediately
unassigns the PCI device from the guest; meanwhile,
create_root_hv_pci_bus() and the PCI device driver can be probing the
dead PCI device and reporting timeout errors.

Fix the issue by adding a per-bus mutex 'state_lock' and grabbing the
mutex before powering on the PCI bus in hv_pci_enter_d0(): when
hv_eject_device_work() starts to run, it's able to find the 'pdev' and call
pci_stop_and_remove_bus_device(pdev): if the PCI device driver has
loaded, the PCI device driver's probe() function is already called in
create_root_hv_pci_bus() -> pci_bus_add_devices(), and now
hv_eject_device_work() -> pci_stop_and_remove_bus_device() is able
to call the PCI device driver's remove() function and remove the device
reliably; if the PCI device driver hasn't loaded yet, the function call
hv_eject_device_work() -> pci_stop_and_remove_bus_device() is able to
remove the PCI device reliably and the PCI device driver's probe()
function won't be called; if the PCI device driver's probe() is already
running (e.g., systemd-udev is loading the PCI device driver), it must
be holding the per-device lock, and after the probe() finishes and releases
the lock, hv_eject_device_work() -> pci_stop_and_remove_bus_device() is
able to proceed to remove the device reliably.

Fixes: 4daace0d8ce8 ("PCI: hv: Add paravirtual PCI front-end for Microsoft Hyper-V VMs")
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Reviewed-by: Michael Kelley <mikelley@microsoft.com>
Cc: stable@vger.kernel.org
(cherry picked from commit 04e9e9f43aee08daeb6089b4cbccba0f70dc95f0 https://github.com/dcui/tdx/commits/decui/vpci/v6.3-rc5-v3)
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>

Author: Long Li
Author Date: 2022-11-03 19:16:30 UTC

RDMA/mana_ib: Add a driver for Microsoft Azure Network Adapter

Add a RDMA VF driver for Microsoft Azure Network Adapter (MANA).

Co-developed-by: Ajay Sharma <sharmaajay@microsoft.com>
Signed-off-by: Ajay Sharma <sharmaajay@microsoft.com>
Reviewed-by: Dexuan Cui <decui@microsoft.com>
Signed-off-by: Long Li <longli@microsoft.com>
Link: https://lore.kernel.org/r/1667502990-2559-13-git-send-email-longli@linuxonhyperv.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
(backported from commit 0266a177631d4c6b963b5b12dd986a8c5abdbf06)
rtg - context adjustments, RDMA_DRIVER_UNKNOWN goes in include/uapi/rdma/rdma_user_ioctl_cmds.h]
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>

Author: Haiyang Zhang
Author Date: 2022-12-02 19:43:10 UTC

net: mana: Fix race on per-CQ variable napi work_done

BugLink: https://bugs.launchpad.net/bugs/2003353

After calling napi_complete_done(), the NAPIF_STATE_SCHED bit may be
cleared, and another CPU can start napi thread and access per-CQ variable,
cq->work_done. If the other thread (for example, from busy_poll) sets
it to a value >= budget, this thread will continue to run when it should
stop, and cause memory corruption and panic.

To fix this issue, save the per-CQ work_done variable in a local variable
before napi_complete_done(), so it won't be corrupted by a possible
concurrent thread after napi_complete_done().

Also, add a flag bit to advertise to the NIC firmware: the NAPI work_done
variable race is fixed, so the driver is able to reliably support features
like busy_poll.

Cc: stable@vger.kernel.org
Fixes: e1b5683ff62e ("net: mana: Move NAPI from EQ to CQ")
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Link: https://lore.kernel.org/r/1670010190-28595-1-git-send-email-haiyangz@microsoft.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
(cherry picked from commit 18010ff776fa42340efc428b3ea6d19b3e7c7b21)
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>

Author: Tim Gardner
Author Date: 2022-10-27 13:38:41 UTC

5.4.0-1096.102~lp1994974.1

Signed-off-by: Tim Gardner <tim.gardner@canonical.com>

Author: Tim Gardner
Author Date: 2022-10-07 16:17:29 UTC

5.4.0-1087.94~lp1991975.1

Signed-off-by: Tim Gardner <tim.gardner@canonical.com>

Author: Tim Gardner
Author Date: 2022-09-26 17:36:59 UTC

UBUNTU: Ubuntu-azure-5.4.0-1093.98

Signed-off-by: Tim Gardner <tim.gardner@canonical.com>

Author: Tim Gardner
Author Date: 2022-09-23 16:37:42 UTC

UBUNTU: Ubuntu-azure-5.15-5.15.0-1021.26~20.04.1

Signed-off-by: Tim Gardner <tim.gardner@canonical.com>

Author: Dexuan Cui
Author Date: 2022-08-04 02:51:04 UTC

UBUNTU: SAUCE: PCI: hv: Only reuse existing IRTE allocation for Multi-MSI

BugLink: https://bugs.launchpad.net/bugs/1990184

Jeffrey's 4 recent patches added Multi-MSI support to the pci-hyperv driver.
Unluckily, one of the patches, i.e., b4b77778ecc5, causes a regression to a
fio test for the Azure VM SKU Standard L64s v2 (64 AMD vCPUs, 8 NVMe drives):

when fio runs against all the 8 NVMe drives, it runs fine with a low io-depth
(e.g., 2 or 4); when fio runs with a high io-depth (e.g., 256), somehow
queue-29 of each NVMe drive suddenly no longer receives any interrupts, and
the NVMe core code has to abort the queue after a timeout of 30 seconds, and
then queue-29 starts to receive interrupts again for several seconds, and
later queue-29 no longer receives interrupts again, and this pattern repeats:

[ 223.891249] nvme nvme2: I/O 320 QID 29 timeout, aborting
[ 223.896231] nvme nvme0: I/O 320 QID 29 timeout, aborting
[ 223.898340] nvme nvme4: I/O 832 QID 29 timeout, aborting
[ 259.471309] nvme nvme2: I/O 320 QID 29 timeout, aborting
[ 259.476493] nvme nvme0: I/O 321 QID 29 timeout, aborting
[ 259.482967] nvme nvme0: I/O 322 QID 29 timeout, aborting

Some other symptoms are: the throughput of the NVMe drives drops due to
commit b4b77778ecc5. When the fio test is running, the kernel prints some
soft lock-up messages from time to time.

Commit b4b77778ecc5 itself looks good, and at the moment it's unclear where
the issue is. While the issue is being investigated, restore the old behavior
in hv_compose_msi_msg(), i.e., don't reuse the existing IRTE allocation for
single-MSI and MSI-X. This is a stopgap for the above NVMe issue.

Fixes: b4b77778ecc5 ("PCI: hv: Reuse existing IRTE allocation in compose_msi_msg()")
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Cc: Jeffrey Hugo <quic_jhugo@quicinc.com>
Cc: Carl Vanderlip <quic_carlv@quicinc.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>

Author: Tim Gardner
Author Date: 2022-09-22 16:58:21 UTC

UBUNTU: Ubuntu-azure-5.4.0-1092.97

Signed-off-by: Tim Gardner <tim.gardner@canonical.com>

Author: Tim Gardner
Author Date: 2022-09-22 13:15:40 UTC

UBUNTU: Ubuntu-aws-5.15-5.15.0-1021.25~20.04.1

Signed-off-by: Tim Gardner <tim.gardner@canonical.com>

Author: Tim Gardner
Author Date: 2022-09-16 19:08:34 UTC

5.4.0-1092.97~lp1990009.1

Signed-off-by: Tim Gardner <tim.gardner@canonical.com>

Author: Tim Gardner
Author Date: 2022-09-02 17:24:35 UTC

5.15.0-1020.25~20.04.2.sf00343105.1

Signed-off-by: Tim Gardner <tim.gardner@canonical.com>

Author: Tim Gardner
Author Date: 2022-07-19 15:12:00 UTC

Initial revision

Signed-off-by: Tim Gardner <tim.gardner@canonical.com>

Author: Tim Gardner
Author Date: 2022-07-12 19:28:45 UTC

5.4.0-1087.92~sf00340353.1

Signed-off-by: Tim Gardner <tim.gardner@canonical.com>

Author: Tim Gardner
Author Date: 2022-06-13 16:41:36 UTC

5.13.0-1028.31~lp1978475.1.20.04.1

Signed-off-by: Tim Gardner <tim.gardner@canonical.com>

Author: Tim Gardner
Author Date: 2022-05-09 14:45:11 UTC

5.4.0-1079.82~lp1972662.1

Signed-off-by: Tim Gardner <tim.gardner@canonical.com>

Author: Tim Gardner
Author Date: 2022-05-04 18:35:13 UTC

UBUNTU: Start new release

Ignore: yes
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>

Author: Tim Gardner
Author Date: 2022-05-03 18:25:31 UTC

UBUNTU: Start new release

Ignore: yes
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>

Author: Tim Gardner
Author Date: 2022-04-13 18:44:59 UTC

UBUNTU: [Config] azure: Homgenize arm64 config settings against amd64

BugLink: https://bugs.launchpad.net/bugs/1968900

Signed-off-by: Tim Gardner <tim.gardner@canonical.com>

Author: Tim Gardner
Author Date: 2022-04-08 13:07:49 UTC

UBUNTU: SAUCE: Fixup MSI domain ops

BugLink: https://bugs.launchpad.net/bugs/1965618

Regarding a crash when mlx5_ib is loading:

Hi Tim,

I think I found the root cause. With the help from Lili, I'm able to get
a core dump, and in that dump I found:

crash> struct msi_domain_ops 0xffffffffa075a6a0
struct msi_domain_ops {
  get_hwirq = 0x0,
  msi_init = 0xffffffff9ecfe3a0,
  msi_free = 0xffffffff9f176430,
  msi_check = 0xffffffff9f16e9f0,
  msi_prepare = 0xffffffff9f175800,
  msi_finish = 0x0,
  set_desc = 0x0,
  handle_error = 0xffffffff9f16e5f0
}

->set_desc is the function pointer that caused the crash.

Why that point is NULL? It's because on x86 + 5.4, we have:

in drivers/pci/msi.c

1477 #else // GENERIC_MSI_DOMAIN_OPS is not set on x86
1478 #define pci_msi_domain_set_desc NULL
1479 #endif

and function pci_msi_domain_update_dom_ops():

1493 } else {
1494 if (ops->set_desc == NULL)
1495 ops->set_desc = pci_msi_domain_set_desc;

So if we don't provide a ->set_desc before calling pci_msi_create_irq_domain(),
->set_desc will end up being NULL.

The difference between x86 and ARM64 is gone after Thomas' patset:

https://lore.kernel.org/all/160026913589.15536.1984671925148098137.tip-bot2@tip-bot2/t/#m8be1d89b42ab1e541e308c203ebcad094115074d

So the upstream vPCI support from Sunil is based on this and the current backport
stayed close to the upstream version and removed the set of ->get_hwirq and
->set_desc, and the that caused the crash.

I think the below will fix the problem.

Regards,
Boqun

Signed-off-by: Tim Gardner <tim.gardner@canonical.com>

Author: Tim Gardner
Author Date: 2022-03-15 19:09:02 UTC

5.4.0-1070.74~sf00330794.1

Signed-off-by: Tim Gardner <tim.gardner@canonical.com>

Author: Tim Gardner
Author Date: 2022-03-03 20:55:54 UTC

5.4.0-1072.75~lp1962610.2

Signed-off-by: Tim Gardner <tim.gardner@canonical.com>

Author: Lijun Pan
Author Date: 2020-12-14 21:19:30 UTC

use __netdev_notify_peers in hyperv

Start to use the lockless version of netdev_notify_peers.
Call the helper where notify variable used to be set true.
Remove the notify bool variable and sort the variables
in reverse Christmas tree order.

Cc: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: Lijun Pan <ljp@linux.ibm.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
(cherry picked from commit 935d8a0a43e3f928e3243ae22bc53cd7a014d515)
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>

Author: Tim Gardner
Author Date: 2022-01-14 13:12:38 UTC

UBUNTU: Ubuntu-azure-5.13-5.13.0-1011.12~20.04.1.lp1949770.1

Signed-off-by: Tim Gardner <tim.gardner@canonical.com>

Author: Tim Gardner
Author Date: 2022-01-07 20:50:00 UTC

5.4.0-1066.69~sf00324445.1

Signed-off-by: Tim Gardner <tim.gardner@canonical.com>

Author: Tim Gardner
Author Date: 2021-11-23 13:41:00 UTC

5.11.0-1023.24+arm64.2~20.04.1

Signed-off-by: Tim Gardner <tim.gardner@canonical.com>

Author: Andra Paraschiv
Author Date: 2021-08-27 15:49:30 UTC

nitro_enclaves: Add fixes for checkpatch blank line reports

BugLink: https://bugs.launchpad.net/bugs/1951873

Remove blank lines that are not necessary, fixing the checkpatch script
reports. While at it, add a blank line after the switch default block,
similar to the other parts of the codebase.

Reviewed-by: George-Aurelian Popescu <popegeo@amazon.com>
Signed-off-by: Andra Paraschiv <andraprs@amazon.com>
Link: https://lore.kernel.org/r/20210827154930.40608-8-andraprs@amazon.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit da1c396a81b87541cf7a7c2c6e128b722461a1c8)
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>

Author: Stefan Bader
Author Date: 2021-10-20 15:26:24 UTC

UBUNTU: Ubuntu-hwe-5.11-5.11.0-40.44~20.04.1

Signed-off-by: Stefan Bader <stefan.bader@canonical.com>

Author: Stefan Bader
Author Date: 2021-10-20 15:26:24 UTC

UBUNTU: Ubuntu-hwe-5.11-5.11.0-40.44~20.04.1

Signed-off-by: Stefan Bader <stefan.bader@canonical.com>

Author: Haiyang Zhang
Author Date: 2021-10-08 13:11:31 UTC

net: mana: Fix error handling in mana_create_rxq()

BugLink: https://bugs.launchpad.net/bugs/1947859

Fix error handling in mana_create_rxq() when
cq->gdma_id >= gc->max_num_cqs.

Fixes: ca9c54d2d6a5 ("net: mana: Add a driver for Microsoft Azure Network Adapter (MANA)")
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Link: https://lore.kernel.org/r/1633698691-31721-1-git-send-email-haiyangz@microsoft.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
(cherry picked from commit be0499369d6376e70b5b80bbced94c0c32d508b1)
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>

Author: Kelsey Steele
Author Date: 2021-10-15 17:56:24 UTC

UBUNTU: Ubuntu-5.4.0-90.101

Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>

Author: Kelsey Steele
Author Date: 2021-10-15 17:56:24 UTC

UBUNTU: Ubuntu-5.4.0-90.101

Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>

Author: Jason Gunthorpe
Author Date: 2021-10-11 22:08:00 UTC

RDMA/ucma: Rework ucma_migrate_id() to avoid races with destroy

ucma_destroy_id() assumes that all things accessing the ctx will do so via
the xarray. This assumption violated only in the case the FD is being
closed, then the ctx is reached via the ctx_list. Normally this is OK
since ucma_destroy_id() cannot run concurrenty with release(), however
with ucma_migrate_id() is involved this can violated as the close of the
2nd FD can run concurrently with destroy on the first:

                CPU0 CPU1
        ucma_destroy_id(fda)
                                  ucma_migrate_id(fda -> fdb)
                                       ucma_get_ctx()
        xa_lock()
         _ucma_find_context()
         xa_erase()
        xa_unlock()
                                       xa_lock()
                                        ctx->file = new_file
                                        list_move()
                                       xa_unlock()
                                      ucma_put_ctx()

                                   ucma_close(fdb)
                                      _destroy_id()
                                      kfree(ctx)

        _destroy_id()
          wait_for_completion()
          // boom, ctx was freed

The ctx->file must be modified under the handler and xa_lock, and prior to
modification the ID must be rechecked that it is still reachable from
cur_file, ie there is no parallel destroy or migrate.

To make this work remove the double locking and streamline the control
flow. The double locking was obsoleted by the handler lock now directly
preventing new uevents from being created, and the ctx_list cannot be read
while holding fgets on both files. Removing the double locking also
removes the need to check for the same file.

Fixes: 88314e4dda1e ("RDMA/cma: add support for rdma_migrate_id()")
Link: https://lore.kernel.org/r/0-v1-05c5a4090305+3a872-ucma_syz_migrate_jgg@nvidia.com
Reported-and-tested-by: syzbot+cc6fc752b3819e082d0c@syzkaller.appspotmail.com
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
(cherry picked from commit f5449e74802c1112dea984aec8af7a33c4516af1)
CVE-2020-36385
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>

Author: Dimitri John Ledkov
Author Date: 2021-10-01 09:33:00 UTC

UBUNTU: [Config] Re-enable CONFIG_DEBUG_INFO_BTF on all arches

New backport of pahole is now available that works with new enough
kernels and on 32-bit arches, thus it is now possible to re-enable
CONFIG_DEBUG_INFO_BTF on all arches.

BugLink: https://bugs.launchpad.net/bugs/1945632
Signed-off-by: Dimitri John Ledkov <dimitri.ledkov@canonical.com>
Acked-by: Andrea Righi <andrea.righi@canonical.com>
Acked-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>

Author: Stefan Bader
Author Date: 2021-10-05 08:54:57 UTC

UBUNTU: Ubuntu-hwe-5.8-5.8.0-66.74

Signed-off-by: Stefan Bader <stefan.bader@canonical.com>

Author: Kelsey Steele
Author Date: 2021-09-23 16:40:49 UTC

UBUNTU: Ubuntu-5.4.0-88.99

Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>

Author: Andrea Righi
Author Date: 2021-08-24 13:51:26 UTC

UBUNTU: Ubuntu-hwe-5.13-5.13.0-14.14~20.04.3

Signed-off-by: Andrea Righi <andrea.righi@canonical.com>