]> git.ipfire.org Git - thirdparty/kernel/stable-queue.git/commitdiff
Fixes for 5.4
authorSasha Levin <sashal@kernel.org>
Mon, 13 Apr 2020 23:47:00 +0000 (19:47 -0400)
committerSasha Levin <sashal@kernel.org>
Mon, 13 Apr 2020 23:47:00 +0000 (19:47 -0400)
Signed-off-by: Sasha Levin <sashal@kernel.org>
69 files changed:
queue-5.4/acpi-ec-do-not-clear-boot_ec_is_ecdt-in-acpi_ec_add.patch [new file with mode: 0644]
queue-5.4/arm-dts-fix-dm814x-ethernet-by-changing-to-use-rgmii.patch [new file with mode: 0644]
queue-5.4/arm-dts-sun8i-a83t-tbs-a711-hm5065-doesn-t-like-such.patch [new file with mode: 0644]
queue-5.4/block-bfq-fix-use-after-free-in-bfq_idle_slice_timer.patch [new file with mode: 0644]
queue-5.4/block-bfq-move-forward-the-getting-of-an-extra-ref-i.patch [new file with mode: 0644]
queue-5.4/block-fix-use-after-free-issue-accessing-struct-io_c.patch [new file with mode: 0644]
queue-5.4/block-keep-bdi-io_pages-in-sync-with-max_sectors_kb-.patch [new file with mode: 0644]
queue-5.4/bpf-fix-deadlock-with-rq_lock-in-bpf_send_signal.patch [new file with mode: 0644]
queue-5.4/btrfs-qgroup-ensure-qgroup_rescan_running-is-only-se.patch [new file with mode: 0644]
queue-5.4/btrfs-remove-a-bug_on-from-merge_reloc_roots.patch [new file with mode: 0644]
queue-5.4/btrfs-restart-relocate_tree_blocks-properly.patch [new file with mode: 0644]
queue-5.4/btrfs-track-reloc-roots-based-on-their-commit-root-b.patch [new file with mode: 0644]
queue-5.4/bus-sunxi-rsb-return-correct-data-when-mixing-16-bit.patch [new file with mode: 0644]
queue-5.4/cfg80211-do-not-warn-on-same-channel-at-the-end-of-c.patch [new file with mode: 0644]
queue-5.4/cpufreq-imx6q-fix-error-handling.patch [new file with mode: 0644]
queue-5.4/cpufreq-imx6q-fixes-unwanted-cpu-overclocking-on-i.m.patch [new file with mode: 0644]
queue-5.4/cxgb4-ptp-pass-the-sign-of-offset-delta-in-fw-cmd.patch [new file with mode: 0644]
queue-5.4/debugfs-check-module-state-before-warning-in-full-op.patch [new file with mode: 0644]
queue-5.4/dma-mapping-fix-dma_pgprot-for-unencrypted-coherent-.patch [new file with mode: 0644]
queue-5.4/drm-scheduler-fix-rare-null-ptr-race.patch [new file with mode: 0644]
queue-5.4/efi-x86-ignore-the-memory-attributes-table-on-i386.patch [new file with mode: 0644]
queue-5.4/firmware-arm_sdei-fix-double-lock-on-hibernate-with-.patch [new file with mode: 0644]
queue-5.4/firmware-fix-a-double-abort-case-with-fw_load_sysfs_.patch [new file with mode: 0644]
queue-5.4/genirq-irqdomain-check-pointer-in-irq_domain_alloc_i.patch [new file with mode: 0644]
queue-5.4/gfs2-do-log_flush-in-gfs2_ail_empty_gl-even-if-ail-l.patch [new file with mode: 0644]
queue-5.4/gfs2-don-t-demote-a-glock-until-its-revokes-are-writ.patch [new file with mode: 0644]
queue-5.4/hinic-fix-a-bug-of-waitting-for-io-stopped.patch [new file with mode: 0644]
queue-5.4/hinic-fix-out-of-order-excution-in-arm-cpu.patch [new file with mode: 0644]
queue-5.4/hinic-fix-the-bug-of-clearing-event-queue.patch [new file with mode: 0644]
queue-5.4/hinic-fix-wrong-para-of-wait_for_completion_timeout.patch [new file with mode: 0644]
queue-5.4/hinic-fix-wrong-value-of-min_skb_len.patch [new file with mode: 0644]
queue-5.4/i2c-pca-platform-use-platform_irq_get_optional.patch [new file with mode: 0644]
queue-5.4/i2c-st-fix-missing-struct-parameter-description.patch [new file with mode: 0644]
queue-5.4/input-tm2-touchkey-add-support-for-coreriver-tc360-v.patch [new file with mode: 0644]
queue-5.4/irqchip-gic-v4-provide-irq_retrigger-to-avoid-circul.patch [new file with mode: 0644]
queue-5.4/irqchip-versatile-fpga-handle-chained-irqs-properly.patch [new file with mode: 0644]
queue-5.4/iwlwifi-mvm-fix-rate-scale-nss-configuration.patch [new file with mode: 0644]
queue-5.4/libata-remove-extra-scsi_host_put-in-ata_scsi_add_ho.patch [new file with mode: 0644]
queue-5.4/locking-lockdep-avoid-recursion-in-lockdep_count_-fo.patch [new file with mode: 0644]
queue-5.4/md-check-arrays-is-suspended-in-mddev_detach-before-.patch [new file with mode: 0644]
queue-5.4/media-allegro-fix-type-of-gop_length-in-channel_crea.patch [new file with mode: 0644]
queue-5.4/media-i2c-ov5695-fix-power-on-and-off-sequences.patch [new file with mode: 0644]
queue-5.4/media-i2c-video-i2c-fix-build-errors-due-to-imply-hw.patch [new file with mode: 0644]
queue-5.4/media-imx-imx7-media-csi-fix-video-field-handling.patch [new file with mode: 0644]
queue-5.4/media-imx-imx7_mipi_csis-power-off-the-source-when-s.patch [new file with mode: 0644]
queue-5.4/media-rc-add-keymap-for-videostrong-kii-pro.patch [new file with mode: 0644]
queue-5.4/media-venus-hfi_parser-ignore-hevc-encoding-for-v1.patch [new file with mode: 0644]
queue-5.4/net-stmmac-platform-fix-misleading-interrupt-error-m.patch [new file with mode: 0644]
queue-5.4/net-vxge-fix-wrong-__va_args__-usage.patch [new file with mode: 0644]
queue-5.4/null_blk-fix-spurious-io-errors-after-failed-past-wp.patch [new file with mode: 0644]
queue-5.4/null_blk-fix-the-null_add_dev-error-path.patch [new file with mode: 0644]
queue-5.4/null_blk-handle-null_add_dev-failures-properly.patch [new file with mode: 0644]
queue-5.4/pci-switchtec-fix-init_completion-race-condition-wit.patch [new file with mode: 0644]
queue-5.4/pstore-platform-fix-potential-mem-leak-if-pstore_ini.patch [new file with mode: 0644]
queue-5.4/qlcnic-fix-bad-kzalloc-null-test.patch [new file with mode: 0644]
queue-5.4/rxrpc-abstract-out-the-calculation-of-whether-there-.patch [new file with mode: 0644]
queue-5.4/rxrpc-fix-call-interruptibility-handling.patch [new file with mode: 0644]
queue-5.4/sched-avoid-scale-real-weight-down-to-zero.patch [new file with mode: 0644]
queue-5.4/selftests-net-add-definition-for-sol_dccp-to-fix-com.patch [new file with mode: 0644]
queue-5.4/selftests-x86-ptrace_syscall_32-fix-no-vdso-segfault.patch [new file with mode: 0644]
queue-5.4/series [new file with mode: 0644]
queue-5.4/soc-fsl-dpio-register-dpio-irq-handlers-after-dpio-c.patch [new file with mode: 0644]
queue-5.4/spi-spi-fsl-dspi-replace-interruptible-wait-queue-wi.patch [new file with mode: 0644]
queue-5.4/staging-wilc1000-avoid-double-unlocking-of-wilc-hif_.patch [new file with mode: 0644]
queue-5.4/time-sched_clock-expire-timer-in-hardirq-context.patch [new file with mode: 0644]
queue-5.4/usb-dwc3-core-add-support-for-disabling-ss-instances.patch [new file with mode: 0644]
queue-5.4/x86-boot-use-unsigned-comparison-for-addresses.patch [new file with mode: 0644]
queue-5.4/x86-don-t-let-pgprot_modify-change-the-page-encrypti.patch [new file with mode: 0644]
queue-5.4/xhci-bail-out-early-if-driver-can-t-accress-host-in-.patch [new file with mode: 0644]

diff --git a/queue-5.4/acpi-ec-do-not-clear-boot_ec_is_ecdt-in-acpi_ec_add.patch b/queue-5.4/acpi-ec-do-not-clear-boot_ec_is_ecdt-in-acpi_ec_add.patch
new file mode 100644 (file)
index 0000000..a488e2d
--- /dev/null
@@ -0,0 +1,58 @@
+From fd711882b67654e05681daf95152a7988b7cd018 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 6 Mar 2020 00:15:24 +0100
+Subject: ACPI: EC: Do not clear boot_ec_is_ecdt in acpi_ec_add()
+
+From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+
+[ Upstream commit 65a691f5f8f0bb63d6a82eec7b0ffd193d8d8a5f ]
+
+The reason for clearing boot_ec_is_ecdt in acpi_ec_add() (if a
+PNP0C09 device object matching the ECDT boot EC had been found in
+the namespace) was to cause acpi_ec_ecdt_start() to return early,
+but since the latter does not look at boot_ec_is_ecdt any more,
+acpi_ec_add() need not clear it.
+
+Moreover, doing that may be confusing as it may cause "DSDT" to be
+printed instead of "ECDT" in the EC initialization completion
+message, so stop doing it.
+
+While at it, split the EC initialization completion message into
+two messages, one regarding the boot EC and another one printed
+regardless of whether or not the EC at hand is the boot one.
+
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/acpi/ec.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
+index ca5cdb621c2a7..2dba4e7a83b76 100644
+--- a/drivers/acpi/ec.c
++++ b/drivers/acpi/ec.c
+@@ -1573,7 +1573,6 @@ static int acpi_ec_add(struct acpi_device *device)
+               if (boot_ec && ec->command_addr == boot_ec->command_addr &&
+                   ec->data_addr == boot_ec->data_addr) {
+-                      boot_ec_is_ecdt = false;
+                       /*
+                        * Trust PNP0C09 namespace location rather than
+                        * ECDT ID. But trust ECDT GPE rather than _GPE
+@@ -1593,9 +1592,12 @@ static int acpi_ec_add(struct acpi_device *device)
+       if (ec == boot_ec)
+               acpi_handle_info(boot_ec->handle,
+-                               "Boot %s EC used to handle transactions and events\n",
++                               "Boot %s EC initialization complete\n",
+                                boot_ec_is_ecdt ? "ECDT" : "DSDT");
++      acpi_handle_info(ec->handle,
++                       "EC: Used to handle transactions and events\n");
++
+       device->driver_data = ec;
+       ret = !!request_region(ec->data_addr, 1, "EC data");
+-- 
+2.20.1
+
diff --git a/queue-5.4/arm-dts-fix-dm814x-ethernet-by-changing-to-use-rgmii.patch b/queue-5.4/arm-dts-fix-dm814x-ethernet-by-changing-to-use-rgmii.patch
new file mode 100644 (file)
index 0000000..b5444e7
--- /dev/null
@@ -0,0 +1,83 @@
+From ce22d3ae77b52f7eb408cb3502c36e934124b2d9 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 3 Mar 2020 13:18:36 -0800
+Subject: ARM: dts: Fix dm814x Ethernet by changing to use rgmii-id mode
+
+From: Tony Lindgren <tony@atomide.com>
+
+[ Upstream commit b46b2b7ba6e104d265ab705914859ec0db7a98c5 ]
+
+Commit cd28d1d6e52e ("net: phy: at803x: Disable phy delay for RGMII mode")
+caused a regression for dm814x boards where NFSroot would no longer work.
+
+Let's fix the issue by configuring "rgmii-id" mode as internal delays are
+needed that is no longer the case with "rgmii" mode.
+
+Signed-off-by: Tony Lindgren <tony@atomide.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/arm/boot/dts/dm8148-evm.dts       | 4 ++--
+ arch/arm/boot/dts/dm8148-t410.dts      | 4 ++--
+ arch/arm/boot/dts/dra62x-j5eco-evm.dts | 4 ++--
+ 3 files changed, 6 insertions(+), 6 deletions(-)
+
+diff --git a/arch/arm/boot/dts/dm8148-evm.dts b/arch/arm/boot/dts/dm8148-evm.dts
+index 3931fb068ff09..91d1018ab75fc 100644
+--- a/arch/arm/boot/dts/dm8148-evm.dts
++++ b/arch/arm/boot/dts/dm8148-evm.dts
+@@ -24,12 +24,12 @@
+ &cpsw_emac0 {
+       phy-handle = <&ethphy0>;
+-      phy-mode = "rgmii";
++      phy-mode = "rgmii-id";
+ };
+ &cpsw_emac1 {
+       phy-handle = <&ethphy1>;
+-      phy-mode = "rgmii";
++      phy-mode = "rgmii-id";
+ };
+ &davinci_mdio {
+diff --git a/arch/arm/boot/dts/dm8148-t410.dts b/arch/arm/boot/dts/dm8148-t410.dts
+index 9e43d5ec0bb2f..79ccdd4470f4c 100644
+--- a/arch/arm/boot/dts/dm8148-t410.dts
++++ b/arch/arm/boot/dts/dm8148-t410.dts
+@@ -33,12 +33,12 @@
+ &cpsw_emac0 {
+       phy-handle = <&ethphy0>;
+-      phy-mode = "rgmii";
++      phy-mode = "rgmii-id";
+ };
+ &cpsw_emac1 {
+       phy-handle = <&ethphy1>;
+-      phy-mode = "rgmii";
++      phy-mode = "rgmii-id";
+ };
+ &davinci_mdio {
+diff --git a/arch/arm/boot/dts/dra62x-j5eco-evm.dts b/arch/arm/boot/dts/dra62x-j5eco-evm.dts
+index 861ab90a3f3aa..c16e183822bee 100644
+--- a/arch/arm/boot/dts/dra62x-j5eco-evm.dts
++++ b/arch/arm/boot/dts/dra62x-j5eco-evm.dts
+@@ -24,12 +24,12 @@
+ &cpsw_emac0 {
+       phy-handle = <&ethphy0>;
+-      phy-mode = "rgmii";
++      phy-mode = "rgmii-id";
+ };
+ &cpsw_emac1 {
+       phy-handle = <&ethphy1>;
+-      phy-mode = "rgmii";
++      phy-mode = "rgmii-id";
+ };
+ &davinci_mdio {
+-- 
+2.20.1
+
diff --git a/queue-5.4/arm-dts-sun8i-a83t-tbs-a711-hm5065-doesn-t-like-such.patch b/queue-5.4/arm-dts-sun8i-a83t-tbs-a711-hm5065-doesn-t-like-such.patch
new file mode 100644 (file)
index 0000000..d9dd824
--- /dev/null
@@ -0,0 +1,38 @@
+From 2d05a0746c0095fb9dff2cc837a1b9d6dea128c6 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 22 Feb 2020 23:31:52 +0100
+Subject: ARM: dts: sun8i-a83t-tbs-a711: HM5065 doesn't like such a high
+ voltage
+
+From: Ondrej Jirman <megous@megous.com>
+
+[ Upstream commit a40550952c000667b20082d58077bc647da6c890 ]
+
+Lowering the voltage solves the quick image degradation over time
+(minutes), that was probably caused by overheating.
+
+Signed-off-by: Ondrej Jirman <megous@megous.com>
+Signed-off-by: Maxime Ripard <maxime@cerno.tech>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts b/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts
+index 397140454132f..6bf93e5ed6817 100644
+--- a/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts
++++ b/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts
+@@ -358,8 +358,8 @@
+ };
+ &reg_dldo3 {
+-      regulator-min-microvolt = <2800000>;
+-      regulator-max-microvolt = <2800000>;
++      regulator-min-microvolt = <1800000>;
++      regulator-max-microvolt = <1800000>;
+       regulator-name = "vdd-csi";
+ };
+-- 
+2.20.1
+
diff --git a/queue-5.4/block-bfq-fix-use-after-free-in-bfq_idle_slice_timer.patch b/queue-5.4/block-bfq-fix-use-after-free-in-bfq_idle_slice_timer.patch
new file mode 100644 (file)
index 0000000..ddee2af
--- /dev/null
@@ -0,0 +1,178 @@
+From 3b20431ca23f90e8a6e752048674c03fc1c95926 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 19 Mar 2020 19:18:13 +0800
+Subject: block, bfq: fix use-after-free in bfq_idle_slice_timer_body
+
+From: Zhiqiang Liu <liuzhiqiang26@huawei.com>
+
+[ Upstream commit 2f95fa5c955d0a9987ffdc3a095e2f4e62c5f2a9 ]
+
+In bfq_idle_slice_timer func, bfqq = bfqd->in_service_queue is
+not in bfqd-lock critical section. The bfqq, which is not
+equal to NULL in bfq_idle_slice_timer, may be freed after passing
+to bfq_idle_slice_timer_body. So we will access the freed memory.
+
+In addition, considering the bfqq may be in race, we should
+firstly check whether bfqq is in service before doing something
+on it in bfq_idle_slice_timer_body func. If the bfqq in race is
+not in service, it means the bfqq has been expired through
+__bfq_bfqq_expire func, and wait_request flags has been cleared in
+__bfq_bfqd_reset_in_service func. So we do not need to re-clear the
+wait_request of bfqq which is not in service.
+
+KASAN log is given as follows:
+[13058.354613] ==================================================================
+[13058.354640] BUG: KASAN: use-after-free in bfq_idle_slice_timer+0xac/0x290
+[13058.354644] Read of size 8 at addr ffffa02cf3e63f78 by task fork13/19767
+[13058.354646]
+[13058.354655] CPU: 96 PID: 19767 Comm: fork13
+[13058.354661] Call trace:
+[13058.354667]  dump_backtrace+0x0/0x310
+[13058.354672]  show_stack+0x28/0x38
+[13058.354681]  dump_stack+0xd8/0x108
+[13058.354687]  print_address_description+0x68/0x2d0
+[13058.354690]  kasan_report+0x124/0x2e0
+[13058.354697]  __asan_load8+0x88/0xb0
+[13058.354702]  bfq_idle_slice_timer+0xac/0x290
+[13058.354707]  __hrtimer_run_queues+0x298/0x8b8
+[13058.354710]  hrtimer_interrupt+0x1b8/0x678
+[13058.354716]  arch_timer_handler_phys+0x4c/0x78
+[13058.354722]  handle_percpu_devid_irq+0xf0/0x558
+[13058.354731]  generic_handle_irq+0x50/0x70
+[13058.354735]  __handle_domain_irq+0x94/0x110
+[13058.354739]  gic_handle_irq+0x8c/0x1b0
+[13058.354742]  el1_irq+0xb8/0x140
+[13058.354748]  do_wp_page+0x260/0xe28
+[13058.354752]  __handle_mm_fault+0x8ec/0x9b0
+[13058.354756]  handle_mm_fault+0x280/0x460
+[13058.354762]  do_page_fault+0x3ec/0x890
+[13058.354765]  do_mem_abort+0xc0/0x1b0
+[13058.354768]  el0_da+0x24/0x28
+[13058.354770]
+[13058.354773] Allocated by task 19731:
+[13058.354780]  kasan_kmalloc+0xe0/0x190
+[13058.354784]  kasan_slab_alloc+0x14/0x20
+[13058.354788]  kmem_cache_alloc_node+0x130/0x440
+[13058.354793]  bfq_get_queue+0x138/0x858
+[13058.354797]  bfq_get_bfqq_handle_split+0xd4/0x328
+[13058.354801]  bfq_init_rq+0x1f4/0x1180
+[13058.354806]  bfq_insert_requests+0x264/0x1c98
+[13058.354811]  blk_mq_sched_insert_requests+0x1c4/0x488
+[13058.354818]  blk_mq_flush_plug_list+0x2d4/0x6e0
+[13058.354826]  blk_flush_plug_list+0x230/0x548
+[13058.354830]  blk_finish_plug+0x60/0x80
+[13058.354838]  read_pages+0xec/0x2c0
+[13058.354842]  __do_page_cache_readahead+0x374/0x438
+[13058.354846]  ondemand_readahead+0x24c/0x6b0
+[13058.354851]  page_cache_sync_readahead+0x17c/0x2f8
+[13058.354858]  generic_file_buffered_read+0x588/0xc58
+[13058.354862]  generic_file_read_iter+0x1b4/0x278
+[13058.354965]  ext4_file_read_iter+0xa8/0x1d8 [ext4]
+[13058.354972]  __vfs_read+0x238/0x320
+[13058.354976]  vfs_read+0xbc/0x1c0
+[13058.354980]  ksys_read+0xdc/0x1b8
+[13058.354984]  __arm64_sys_read+0x50/0x60
+[13058.354990]  el0_svc_common+0xb4/0x1d8
+[13058.354994]  el0_svc_handler+0x50/0xa8
+[13058.354998]  el0_svc+0x8/0xc
+[13058.354999]
+[13058.355001] Freed by task 19731:
+[13058.355007]  __kasan_slab_free+0x120/0x228
+[13058.355010]  kasan_slab_free+0x10/0x18
+[13058.355014]  kmem_cache_free+0x288/0x3f0
+[13058.355018]  bfq_put_queue+0x134/0x208
+[13058.355022]  bfq_exit_icq_bfqq+0x164/0x348
+[13058.355026]  bfq_exit_icq+0x28/0x40
+[13058.355030]  ioc_exit_icq+0xa0/0x150
+[13058.355035]  put_io_context_active+0x250/0x438
+[13058.355038]  exit_io_context+0xd0/0x138
+[13058.355045]  do_exit+0x734/0xc58
+[13058.355050]  do_group_exit+0x78/0x220
+[13058.355054]  __wake_up_parent+0x0/0x50
+[13058.355058]  el0_svc_common+0xb4/0x1d8
+[13058.355062]  el0_svc_handler+0x50/0xa8
+[13058.355066]  el0_svc+0x8/0xc
+[13058.355067]
+[13058.355071] The buggy address belongs to the object at ffffa02cf3e63e70#012 which belongs to the cache bfq_queue of size 464
+[13058.355075] The buggy address is located 264 bytes inside of#012 464-byte region [ffffa02cf3e63e70, ffffa02cf3e64040)
+[13058.355077] The buggy address belongs to the page:
+[13058.355083] page:ffff7e80b3cf9800 count:1 mapcount:0 mapping:ffff802db5c90780 index:0xffffa02cf3e606f0 compound_mapcount: 0
+[13058.366175] flags: 0x2ffffe0000008100(slab|head)
+[13058.370781] raw: 2ffffe0000008100 ffff7e80b53b1408 ffffa02d730c1c90 ffff802db5c90780
+[13058.370787] raw: ffffa02cf3e606f0 0000000000370023 00000001ffffffff 0000000000000000
+[13058.370789] page dumped because: kasan: bad access detected
+[13058.370791]
+[13058.370792] Memory state around the buggy address:
+[13058.370797]  ffffa02cf3e63e00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fb fb
+[13058.370801]  ffffa02cf3e63e80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
+[13058.370805] >ffffa02cf3e63f00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
+[13058.370808]                                                                 ^
+[13058.370811]  ffffa02cf3e63f80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
+[13058.370815]  ffffa02cf3e64000: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
+[13058.370817] ==================================================================
+[13058.370820] Disabling lock debugging due to kernel taint
+
+Here, we directly pass the bfqd to bfq_idle_slice_timer_body func.
+--
+V2->V3: rewrite the comment as suggested by Paolo Valente
+V1->V2: add one comment, and add Fixes and Reported-by tag.
+
+Fixes: aee69d78d ("block, bfq: introduce the BFQ-v0 I/O scheduler as an extra scheduler")
+Acked-by: Paolo Valente <paolo.valente@linaro.org>
+Reported-by: Wang Wang <wangwang2@huawei.com>
+Signed-off-by: Zhiqiang Liu <liuzhiqiang26@huawei.com>
+Signed-off-by: Feilong Lin <linfeilong@huawei.com>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ block/bfq-iosched.c | 16 ++++++++++++----
+ 1 file changed, 12 insertions(+), 4 deletions(-)
+
+diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
+index 48189ff88916e..5a825f9f1ea0b 100644
+--- a/block/bfq-iosched.c
++++ b/block/bfq-iosched.c
+@@ -6210,20 +6210,28 @@ static struct bfq_queue *bfq_init_rq(struct request *rq)
+       return bfqq;
+ }
+-static void bfq_idle_slice_timer_body(struct bfq_queue *bfqq)
++static void
++bfq_idle_slice_timer_body(struct bfq_data *bfqd, struct bfq_queue *bfqq)
+ {
+-      struct bfq_data *bfqd = bfqq->bfqd;
+       enum bfqq_expiration reason;
+       unsigned long flags;
+       spin_lock_irqsave(&bfqd->lock, flags);
+-      bfq_clear_bfqq_wait_request(bfqq);
++      /*
++       * Considering that bfqq may be in race, we should firstly check
++       * whether bfqq is in service before doing something on it. If
++       * the bfqq in race is not in service, it has already been expired
++       * through __bfq_bfqq_expire func and its wait_request flags has
++       * been cleared in __bfq_bfqd_reset_in_service func.
++       */
+       if (bfqq != bfqd->in_service_queue) {
+               spin_unlock_irqrestore(&bfqd->lock, flags);
+               return;
+       }
++      bfq_clear_bfqq_wait_request(bfqq);
++
+       if (bfq_bfqq_budget_timeout(bfqq))
+               /*
+                * Also here the queue can be safely expired
+@@ -6268,7 +6276,7 @@ static enum hrtimer_restart bfq_idle_slice_timer(struct hrtimer *timer)
+        * early.
+        */
+       if (bfqq)
+-              bfq_idle_slice_timer_body(bfqq);
++              bfq_idle_slice_timer_body(bfqd, bfqq);
+       return HRTIMER_NORESTART;
+ }
+-- 
+2.20.1
+
diff --git a/queue-5.4/block-bfq-move-forward-the-getting-of-an-extra-ref-i.patch b/queue-5.4/block-bfq-move-forward-the-getting-of-an-extra-ref-i.patch
new file mode 100644 (file)
index 0000000..3d05272
--- /dev/null
@@ -0,0 +1,73 @@
+From e33cae48b880975cf3508ea00e96adfc01994408 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 21 Mar 2020 10:45:18 +0100
+Subject: block, bfq: move forward the getting of an extra ref in bfq_bfqq_move
+
+From: Paolo Valente <paolo.valente@linaro.org>
+
+[ Upstream commit fd1bb3ae54a9a2e0c42709de861c69aa146b8955 ]
+
+Commit ecedd3d7e199 ("block, bfq: get extra ref to prevent a queue
+from being freed during a group move") gets an extra reference to a
+bfq_queue before possibly deactivating it (temporarily), in
+bfq_bfqq_move(). This prevents the bfq_queue from disappearing before
+being reactivated in its new group.
+
+Yet, the bfq_queue may also be expired (i.e., its service may be
+stopped) before the bfq_queue is deactivated. And also an expiration
+may lead to a premature freeing. This commit fixes this issue by
+simply moving forward the getting of the extra reference already
+introduced by commit ecedd3d7e199 ("block, bfq: get extra ref to
+prevent a queue from being freed during a group move").
+
+Reported-by: cki-project@redhat.com
+Tested-by: cki-project@redhat.com
+Signed-off-by: Paolo Valente <paolo.valente@linaro.org>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ block/bfq-cgroup.c | 14 +++++++-------
+ 1 file changed, 7 insertions(+), 7 deletions(-)
+
+diff --git a/block/bfq-cgroup.c b/block/bfq-cgroup.c
+index 86cd718e0380b..5611769e15690 100644
+--- a/block/bfq-cgroup.c
++++ b/block/bfq-cgroup.c
+@@ -625,6 +625,12 @@ void bfq_bfqq_move(struct bfq_data *bfqd, struct bfq_queue *bfqq,
+ {
+       struct bfq_entity *entity = &bfqq->entity;
++      /*
++       * Get extra reference to prevent bfqq from being freed in
++       * next possible expire or deactivate.
++       */
++      bfqq->ref++;
++
+       /* If bfqq is empty, then bfq_bfqq_expire also invokes
+        * bfq_del_bfqq_busy, thereby removing bfqq and its entity
+        * from data structures related to current group. Otherwise we
+@@ -635,12 +641,6 @@ void bfq_bfqq_move(struct bfq_data *bfqd, struct bfq_queue *bfqq,
+               bfq_bfqq_expire(bfqd, bfqd->in_service_queue,
+                               false, BFQQE_PREEMPTED);
+-      /*
+-       * get extra reference to prevent bfqq from being freed in
+-       * next possible deactivate
+-       */
+-      bfqq->ref++;
+-
+       if (bfq_bfqq_busy(bfqq))
+               bfq_deactivate_bfqq(bfqd, bfqq, false, false);
+       else if (entity->on_st)
+@@ -660,7 +660,7 @@ void bfq_bfqq_move(struct bfq_data *bfqd, struct bfq_queue *bfqq,
+       if (!bfqd->in_service_queue && !bfqd->rq_in_driver)
+               bfq_schedule_dispatch(bfqd);
+-      /* release extra ref taken above */
++      /* release extra ref taken above, bfqq may happen to be freed now */
+       bfq_put_queue(bfqq);
+ }
+-- 
+2.20.1
+
diff --git a/queue-5.4/block-fix-use-after-free-issue-accessing-struct-io_c.patch b/queue-5.4/block-fix-use-after-free-issue-accessing-struct-io_c.patch
new file mode 100644 (file)
index 0000000..1e722d1
--- /dev/null
@@ -0,0 +1,115 @@
+From c9725ca0c5eda824dce0b5bfeedaceeda1689a4c Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 11 Mar 2020 16:07:50 +0530
+Subject: block: Fix use-after-free issue accessing struct io_cq
+
+From: Sahitya Tummala <stummala@codeaurora.org>
+
+[ Upstream commit 30a2da7b7e225ef6c87a660419ea04d3cef3f6a7 ]
+
+There is a potential race between ioc_release_fn() and
+ioc_clear_queue() as shown below, due to which below kernel
+crash is observed. It also can result into use-after-free
+issue.
+
+context#1:                             context#2:
+ioc_release_fn()                       __ioc_clear_queue() gets the same icq
+->spin_lock(&ioc->lock);               ->spin_lock(&ioc->lock);
+->ioc_destroy_icq(icq);
+  ->list_del_init(&icq->q_node);
+  ->call_rcu(&icq->__rcu_head,
+       icq_free_icq_rcu);
+->spin_unlock(&ioc->lock);
+                                       ->ioc_destroy_icq(icq);
+                                         ->hlist_del_init(&icq->ioc_node);
+                                         This results into below crash as this memory
+                                         is now used by icq->__rcu_head in context#1.
+                                         There is a chance that icq could be free'd
+                                         as well.
+
+22150.386550:   <6> Unable to handle kernel write to read-only memory
+at virtual address ffffffaa8d31ca50
+...
+Call trace:
+22150.607350:   <2>  ioc_destroy_icq+0x44/0x110
+22150.611202:   <2>  ioc_clear_queue+0xac/0x148
+22150.615056:   <2>  blk_cleanup_queue+0x11c/0x1a0
+22150.619174:   <2>  __scsi_remove_device+0xdc/0x128
+22150.623465:   <2>  scsi_forget_host+0x2c/0x78
+22150.627315:   <2>  scsi_remove_host+0x7c/0x2a0
+22150.631257:   <2>  usb_stor_disconnect+0x74/0xc8
+22150.635371:   <2>  usb_unbind_interface+0xc8/0x278
+22150.639665:   <2>  device_release_driver_internal+0x198/0x250
+22150.644897:   <2>  device_release_driver+0x24/0x30
+22150.649176:   <2>  bus_remove_device+0xec/0x140
+22150.653204:   <2>  device_del+0x270/0x460
+22150.656712:   <2>  usb_disable_device+0x120/0x390
+22150.660918:   <2>  usb_disconnect+0xf4/0x2e0
+22150.664684:   <2>  hub_event+0xd70/0x17e8
+22150.668197:   <2>  process_one_work+0x210/0x480
+22150.672222:   <2>  worker_thread+0x32c/0x4c8
+
+Fix this by adding a new ICQ_DESTROYED flag in ioc_destroy_icq() to
+indicate this icq is once marked as destroyed. Also, ensure
+__ioc_clear_queue() is accessing icq within rcu_read_lock/unlock so
+that icq doesn't get free'd up while it is still using it.
+
+Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
+Co-developed-by: Pradeep P V K <ppvk@codeaurora.org>
+Signed-off-by: Pradeep P V K <ppvk@codeaurora.org>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ block/blk-ioc.c           | 7 +++++++
+ include/linux/iocontext.h | 1 +
+ 2 files changed, 8 insertions(+)
+
+diff --git a/block/blk-ioc.c b/block/blk-ioc.c
+index 5ed59ac6ae58b..9df50fb507caf 100644
+--- a/block/blk-ioc.c
++++ b/block/blk-ioc.c
+@@ -84,6 +84,7 @@ static void ioc_destroy_icq(struct io_cq *icq)
+        * making it impossible to determine icq_cache.  Record it in @icq.
+        */
+       icq->__rcu_icq_cache = et->icq_cache;
++      icq->flags |= ICQ_DESTROYED;
+       call_rcu(&icq->__rcu_head, icq_free_icq_rcu);
+ }
+@@ -212,15 +213,21 @@ static void __ioc_clear_queue(struct list_head *icq_list)
+ {
+       unsigned long flags;
++      rcu_read_lock();
+       while (!list_empty(icq_list)) {
+               struct io_cq *icq = list_entry(icq_list->next,
+                                               struct io_cq, q_node);
+               struct io_context *ioc = icq->ioc;
+               spin_lock_irqsave(&ioc->lock, flags);
++              if (icq->flags & ICQ_DESTROYED) {
++                      spin_unlock_irqrestore(&ioc->lock, flags);
++                      continue;
++              }
+               ioc_destroy_icq(icq);
+               spin_unlock_irqrestore(&ioc->lock, flags);
+       }
++      rcu_read_unlock();
+ }
+ /**
+diff --git a/include/linux/iocontext.h b/include/linux/iocontext.h
+index dba15ca8e60bc..1dcd9198beb7f 100644
+--- a/include/linux/iocontext.h
++++ b/include/linux/iocontext.h
+@@ -8,6 +8,7 @@
+ enum {
+       ICQ_EXITED              = 1 << 2,
++      ICQ_DESTROYED           = 1 << 3,
+ };
+ /*
+-- 
+2.20.1
+
diff --git a/queue-5.4/block-keep-bdi-io_pages-in-sync-with-max_sectors_kb-.patch b/queue-5.4/block-keep-bdi-io_pages-in-sync-with-max_sectors_kb-.patch
new file mode 100644 (file)
index 0000000..f0b8ffb
--- /dev/null
@@ -0,0 +1,49 @@
+From 00ff9b876a8bab76dd051cee1622ed5a75e82d3f Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 28 Feb 2020 17:51:48 +0300
+Subject: block: keep bdi->io_pages in sync with max_sectors_kb for stacked
+ devices
+
+From: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
+
+[ Upstream commit e74d93e96d721c4297f2a900ad0191890d2fc2b0 ]
+
+Field bdi->io_pages added in commit 9491ae4aade6 ("mm: don't cap request
+size based on read-ahead setting") removes unneeded split of read requests.
+
+Stacked drivers do not call blk_queue_max_hw_sectors(). Instead they set
+limits of their devices by blk_set_stacking_limits() + disk_stack_limits().
+Field bio->io_pages stays zero until user set max_sectors_kb via sysfs.
+
+This patch updates io_pages after merging limits in disk_stack_limits().
+
+Commit c6d6e9b0f6b4 ("dm: do not allow readahead to limit IO size") fixed
+the same problem for device-mapper devices, this one fixes MD RAIDs.
+
+Fixes: 9491ae4aade6 ("mm: don't cap request size based on read-ahead setting")
+Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
+Reviewed-by: Bob Liu <bob.liu@oracle.com>
+Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
+Signed-off-by: Song Liu <songliubraving@fb.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ block/blk-settings.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/block/blk-settings.c b/block/blk-settings.c
+index c8eda2e7b91e4..be1dca0103a45 100644
+--- a/block/blk-settings.c
++++ b/block/blk-settings.c
+@@ -664,6 +664,9 @@ void disk_stack_limits(struct gendisk *disk, struct block_device *bdev,
+               printk(KERN_NOTICE "%s: Warning: Device %s is misaligned\n",
+                      top, bottom);
+       }
++
++      t->backing_dev_info->io_pages =
++              t->limits.max_sectors >> (PAGE_SHIFT - 9);
+ }
+ EXPORT_SYMBOL(disk_stack_limits);
+-- 
+2.20.1
+
diff --git a/queue-5.4/bpf-fix-deadlock-with-rq_lock-in-bpf_send_signal.patch b/queue-5.4/bpf-fix-deadlock-with-rq_lock-in-bpf_send_signal.patch
new file mode 100644 (file)
index 0000000..f559556
--- /dev/null
@@ -0,0 +1,200 @@
+From c3dbe423ea4bac8fba635bf6d33392df238ce074 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 4 Mar 2020 11:11:04 -0800
+Subject: bpf: Fix deadlock with rq_lock in bpf_send_signal()
+
+From: Yonghong Song <yhs@fb.com>
+
+[ Upstream commit 1bc7896e9ef44fd77858b3ef0b8a6840be3a4494 ]
+
+When experimenting with bpf_send_signal() helper in our production
+environment (5.2 based), we experienced a deadlock in NMI mode:
+   #5 [ffffc9002219f770] queued_spin_lock_slowpath at ffffffff8110be24
+   #6 [ffffc9002219f770] _raw_spin_lock_irqsave at ffffffff81a43012
+   #7 [ffffc9002219f780] try_to_wake_up at ffffffff810e7ecd
+   #8 [ffffc9002219f7e0] signal_wake_up_state at ffffffff810c7b55
+   #9 [ffffc9002219f7f0] __send_signal at ffffffff810c8602
+  #10 [ffffc9002219f830] do_send_sig_info at ffffffff810ca31a
+  #11 [ffffc9002219f868] bpf_send_signal at ffffffff8119d227
+  #12 [ffffc9002219f988] bpf_overflow_handler at ffffffff811d4140
+  #13 [ffffc9002219f9e0] __perf_event_overflow at ffffffff811d68cf
+  #14 [ffffc9002219fa10] perf_swevent_overflow at ffffffff811d6a09
+  #15 [ffffc9002219fa38] ___perf_sw_event at ffffffff811e0f47
+  #16 [ffffc9002219fc30] __schedule at ffffffff81a3e04d
+  #17 [ffffc9002219fc90] schedule at ffffffff81a3e219
+  #18 [ffffc9002219fca0] futex_wait_queue_me at ffffffff8113d1b9
+  #19 [ffffc9002219fcd8] futex_wait at ffffffff8113e529
+  #20 [ffffc9002219fdf0] do_futex at ffffffff8113ffbc
+  #21 [ffffc9002219fec0] __x64_sys_futex at ffffffff81140d1c
+  #22 [ffffc9002219ff38] do_syscall_64 at ffffffff81002602
+  #23 [ffffc9002219ff50] entry_SYSCALL_64_after_hwframe at ffffffff81c00068
+
+The above call stack is actually very similar to an issue
+reported by Commit eac9153f2b58 ("bpf/stackmap: Fix deadlock with
+rq_lock in bpf_get_stack()") by Song Liu. The only difference is
+bpf_send_signal() helper instead of bpf_get_stack() helper.
+
+The above deadlock is triggered with a perf_sw_event.
+Similar to Commit eac9153f2b58, the below almost identical reproducer
+used tracepoint point sched/sched_switch so the issue can be easily caught.
+  /* stress_test.c */
+  #include <stdio.h>
+  #include <stdlib.h>
+  #include <sys/mman.h>
+  #include <pthread.h>
+  #include <sys/types.h>
+  #include <sys/stat.h>
+  #include <fcntl.h>
+
+  #define THREAD_COUNT 1000
+  char *filename;
+  void *worker(void *p)
+  {
+        void *ptr;
+        int fd;
+        char *pptr;
+
+        fd = open(filename, O_RDONLY);
+        if (fd < 0)
+                return NULL;
+        while (1) {
+                struct timespec ts = {0, 1000 + rand() % 2000};
+
+                ptr = mmap(NULL, 4096 * 64, PROT_READ, MAP_PRIVATE, fd, 0);
+                usleep(1);
+                if (ptr == MAP_FAILED) {
+                        printf("failed to mmap\n");
+                        break;
+                }
+                munmap(ptr, 4096 * 64);
+                usleep(1);
+                pptr = malloc(1);
+                usleep(1);
+                pptr[0] = 1;
+                usleep(1);
+                free(pptr);
+                usleep(1);
+                nanosleep(&ts, NULL);
+        }
+        close(fd);
+        return NULL;
+  }
+
+  int main(int argc, char *argv[])
+  {
+        void *ptr;
+        int i;
+        pthread_t threads[THREAD_COUNT];
+
+        if (argc < 2)
+                return 0;
+
+        filename = argv[1];
+
+        for (i = 0; i < THREAD_COUNT; i++) {
+                if (pthread_create(threads + i, NULL, worker, NULL)) {
+                        fprintf(stderr, "Error creating thread\n");
+                        return 0;
+                }
+        }
+
+        for (i = 0; i < THREAD_COUNT; i++)
+                pthread_join(threads[i], NULL);
+        return 0;
+  }
+and the following command:
+  1. run `stress_test /bin/ls` in one windown
+  2. hack bcc trace.py with the following change:
+     --- a/tools/trace.py
+     +++ b/tools/trace.py
+     @@ -513,6 +513,7 @@ BPF_PERF_OUTPUT(%s);
+              __data.tgid = __tgid;
+              __data.pid = __pid;
+              bpf_get_current_comm(&__data.comm, sizeof(__data.comm));
+     +        bpf_send_signal(10);
+      %s
+      %s
+              %s.perf_submit(%s, &__data, sizeof(__data));
+  3. in a different window run
+     ./trace.py -p $(pidof stress_test) t:sched:sched_switch
+
+The deadlock can be reproduced in our production system.
+
+Similar to Song's fix, the fix is to delay sending signal if
+irqs is disabled to avoid deadlocks involving with rq_lock.
+With this change, my above stress-test in our production system
+won't cause deadlock any more.
+
+I also implemented a scale-down version of reproducer in the
+selftest (a subsequent commit). With latest bpf-next,
+it complains for the following potential deadlock.
+  [   32.832450] -> #1 (&p->pi_lock){-.-.}:
+  [   32.833100]        _raw_spin_lock_irqsave+0x44/0x80
+  [   32.833696]        task_rq_lock+0x2c/0xa0
+  [   32.834182]        task_sched_runtime+0x59/0xd0
+  [   32.834721]        thread_group_cputime+0x250/0x270
+  [   32.835304]        thread_group_cputime_adjusted+0x2e/0x70
+  [   32.835959]        do_task_stat+0x8a7/0xb80
+  [   32.836461]        proc_single_show+0x51/0xb0
+  ...
+  [   32.839512] -> #0 (&(&sighand->siglock)->rlock){....}:
+  [   32.840275]        __lock_acquire+0x1358/0x1a20
+  [   32.840826]        lock_acquire+0xc7/0x1d0
+  [   32.841309]        _raw_spin_lock_irqsave+0x44/0x80
+  [   32.841916]        __lock_task_sighand+0x79/0x160
+  [   32.842465]        do_send_sig_info+0x35/0x90
+  [   32.842977]        bpf_send_signal+0xa/0x10
+  [   32.843464]        bpf_prog_bc13ed9e4d3163e3_send_signal_tp_sched+0x465/0x1000
+  [   32.844301]        trace_call_bpf+0x115/0x270
+  [   32.844809]        perf_trace_run_bpf_submit+0x4a/0xc0
+  [   32.845411]        perf_trace_sched_switch+0x10f/0x180
+  [   32.846014]        __schedule+0x45d/0x880
+  [   32.846483]        schedule+0x5f/0xd0
+  ...
+
+  [   32.853148] Chain exists of:
+  [   32.853148]   &(&sighand->siglock)->rlock --> &p->pi_lock --> &rq->lock
+  [   32.853148]
+  [   32.854451]  Possible unsafe locking scenario:
+  [   32.854451]
+  [   32.855173]        CPU0                    CPU1
+  [   32.855745]        ----                    ----
+  [   32.856278]   lock(&rq->lock);
+  [   32.856671]                                lock(&p->pi_lock);
+  [   32.857332]                                lock(&rq->lock);
+  [   32.857999]   lock(&(&sighand->siglock)->rlock);
+
+  Deadlock happens on CPU0 when it tries to acquire &sighand->siglock
+  but it has been held by CPU1 and CPU1 tries to grab &rq->lock
+  and cannot get it.
+
+  This is not exactly the callstack in our production environment,
+  but sympotom is similar and both locks are using spin_lock_irqsave()
+  to acquire the lock, and both involves rq_lock. The fix to delay
+  sending signal when irq is disabled also fixed this issue.
+
+Signed-off-by: Yonghong Song <yhs@fb.com>
+Signed-off-by: Alexei Starovoitov <ast@kernel.org>
+Cc: Song Liu <songliubraving@fb.com>
+Link: https://lore.kernel.org/bpf/20200304191104.2796501-1-yhs@fb.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ kernel/trace/bpf_trace.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
+index 89bdac61233db..2372b861f2cfa 100644
+--- a/kernel/trace/bpf_trace.c
++++ b/kernel/trace/bpf_trace.c
+@@ -650,7 +650,7 @@ BPF_CALL_1(bpf_send_signal, u32, sig)
+       if (unlikely(!nmi_uaccess_okay()))
+               return -EPERM;
+-      if (in_nmi()) {
++      if (irqs_disabled()) {
+               /* Do an early check on signal validity. Otherwise,
+                * the error is lost in deferred irq_work.
+                */
+-- 
+2.20.1
+
diff --git a/queue-5.4/btrfs-qgroup-ensure-qgroup_rescan_running-is-only-se.patch b/queue-5.4/btrfs-qgroup-ensure-qgroup_rescan_running-is-only-se.patch
new file mode 100644 (file)
index 0000000..2b1efcc
--- /dev/null
@@ -0,0 +1,141 @@
+From 62c39c9e655c108d85f6ba5917febddb3e2e6056 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 7 Feb 2020 13:38:20 +0800
+Subject: btrfs: qgroup: ensure qgroup_rescan_running is only set when the
+ worker is at least queued
+
+From: Qu Wenruo <wqu@suse.com>
+
+[ Upstream commit d61acbbf54c612ea9bf67eed609494cda0857b3a ]
+
+[BUG]
+There are some reports about btrfs wait forever to unmount itself, with
+the following call trace:
+
+  INFO: task umount:4631 blocked for more than 491 seconds.
+        Tainted: G               X  5.3.8-2-default #1
+  "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
+  umount          D    0  4631   3337 0x00000000
+  Call Trace:
+  ([<00000000174adf7a>] __schedule+0x342/0x748)
+   [<00000000174ae3ca>] schedule+0x4a/0xd8
+   [<00000000174b1f08>] schedule_timeout+0x218/0x420
+   [<00000000174af10c>] wait_for_common+0x104/0x1d8
+   [<000003ff804d6994>] btrfs_qgroup_wait_for_completion+0x84/0xb0 [btrfs]
+   [<000003ff8044a616>] close_ctree+0x4e/0x380 [btrfs]
+   [<0000000016fa3136>] generic_shutdown_super+0x8e/0x158
+   [<0000000016fa34d6>] kill_anon_super+0x26/0x40
+   [<000003ff8041ba88>] btrfs_kill_super+0x28/0xc8 [btrfs]
+   [<0000000016fa39f8>] deactivate_locked_super+0x68/0x98
+   [<0000000016fcb198>] cleanup_mnt+0xc0/0x140
+   [<0000000016d6a846>] task_work_run+0xc6/0x110
+   [<0000000016d04f76>] do_notify_resume+0xae/0xb8
+   [<00000000174b30ae>] system_call+0xe2/0x2c8
+
+[CAUSE]
+The problem happens when we have called qgroup_rescan_init(), but
+not queued the worker. It can be caused mostly by error handling.
+
+       Qgroup ioctl thread             |       Unmount thread
+----------------------------------------+-----------------------------------
+                                       |
+btrfs_qgroup_rescan()                  |
+|- qgroup_rescan_init()                        |
+|  |- qgroup_rescan_running = true;    |
+|                                      |
+|- trans = btrfs_join_transaction()    |
+|  Some error happened                 |
+|                                      |
+|- btrfs_qgroup_rescan() returns error |
+   But qgroup_rescan_running == true;  |
+                                       | close_ctree()
+                                       | |- btrfs_qgroup_wait_for_completion()
+                                       |    |- running == true;
+                                       |    |- wait_for_completion();
+
+btrfs_qgroup_rescan_worker is never queued, thus no one is going to wake
+up close_ctree() and we get a deadlock.
+
+All involved qgroup_rescan_init() callers are:
+
+- btrfs_qgroup_rescan()
+  The example above. It's possible to trigger the deadlock when error
+  happened.
+
+- btrfs_quota_enable()
+  Not possible. Just after qgroup_rescan_init() we queue the work.
+
+- btrfs_read_qgroup_config()
+  It's possible to trigger the deadlock. It only init the work, the
+  work queueing happens in btrfs_qgroup_rescan_resume().
+  Thus if error happened in between, deadlock is possible.
+
+We shouldn't set fs_info->qgroup_rescan_running just in
+qgroup_rescan_init(), as at that stage we haven't yet queued qgroup
+rescan worker to run.
+
+[FIX]
+Set qgroup_rescan_running before queueing the work, so that we ensure
+the rescan work is queued when we wait for it.
+
+Fixes: 8d9eddad1946 ("Btrfs: fix qgroup rescan worker initialization")
+Signed-off-by: Jeff Mahoney <jeffm@suse.com>
+[ Change subject and cause analyse, use a smaller fix ]
+Signed-off-by: Qu Wenruo <wqu@suse.com>
+Reviewed-by: David Sterba <dsterba@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/btrfs/qgroup.c | 11 +++++++++--
+ 1 file changed, 9 insertions(+), 2 deletions(-)
+
+diff --git a/fs/btrfs/qgroup.c b/fs/btrfs/qgroup.c
+index 286c8c11c8d32..590defdf88609 100644
+--- a/fs/btrfs/qgroup.c
++++ b/fs/btrfs/qgroup.c
+@@ -1030,6 +1030,7 @@ out_add_root:
+       ret = qgroup_rescan_init(fs_info, 0, 1);
+       if (!ret) {
+               qgroup_rescan_zero_tracking(fs_info);
++              fs_info->qgroup_rescan_running = true;
+               btrfs_queue_work(fs_info->qgroup_rescan_workers,
+                                &fs_info->qgroup_rescan_work);
+       }
+@@ -3276,7 +3277,6 @@ qgroup_rescan_init(struct btrfs_fs_info *fs_info, u64 progress_objectid,
+               sizeof(fs_info->qgroup_rescan_progress));
+       fs_info->qgroup_rescan_progress.objectid = progress_objectid;
+       init_completion(&fs_info->qgroup_rescan_completion);
+-      fs_info->qgroup_rescan_running = true;
+       spin_unlock(&fs_info->qgroup_lock);
+       mutex_unlock(&fs_info->qgroup_rescan_lock);
+@@ -3341,8 +3341,11 @@ btrfs_qgroup_rescan(struct btrfs_fs_info *fs_info)
+       qgroup_rescan_zero_tracking(fs_info);
++      mutex_lock(&fs_info->qgroup_rescan_lock);
++      fs_info->qgroup_rescan_running = true;
+       btrfs_queue_work(fs_info->qgroup_rescan_workers,
+                        &fs_info->qgroup_rescan_work);
++      mutex_unlock(&fs_info->qgroup_rescan_lock);
+       return 0;
+ }
+@@ -3378,9 +3381,13 @@ int btrfs_qgroup_wait_for_completion(struct btrfs_fs_info *fs_info,
+ void
+ btrfs_qgroup_rescan_resume(struct btrfs_fs_info *fs_info)
+ {
+-      if (fs_info->qgroup_flags & BTRFS_QGROUP_STATUS_FLAG_RESCAN)
++      if (fs_info->qgroup_flags & BTRFS_QGROUP_STATUS_FLAG_RESCAN) {
++              mutex_lock(&fs_info->qgroup_rescan_lock);
++              fs_info->qgroup_rescan_running = true;
+               btrfs_queue_work(fs_info->qgroup_rescan_workers,
+                                &fs_info->qgroup_rescan_work);
++              mutex_unlock(&fs_info->qgroup_rescan_lock);
++      }
+ }
+ /*
+-- 
+2.20.1
+
diff --git a/queue-5.4/btrfs-remove-a-bug_on-from-merge_reloc_roots.patch b/queue-5.4/btrfs-remove-a-bug_on-from-merge_reloc_roots.patch
new file mode 100644 (file)
index 0000000..b656eb5
--- /dev/null
@@ -0,0 +1,77 @@
+From 55cf59b69266fd1c92a6166b20d88b3d17970b02 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 4 Mar 2020 11:18:30 -0500
+Subject: btrfs: remove a BUG_ON() from merge_reloc_roots()
+
+From: Josef Bacik <josef@toxicpanda.com>
+
+[ Upstream commit 7b7b74315b24dc064bc1c683659061c3d48f8668 ]
+
+This was pretty subtle, we default to reloc roots having 0 root refs, so
+if we crash in the middle of the relocation they can just be deleted.
+If we successfully complete the relocation operations we'll set our root
+refs to 1 in prepare_to_merge() and then go on to merge_reloc_roots().
+
+At prepare_to_merge() time if any of the reloc roots have a 0 reference
+still, we will remove that reloc root from our reloc root rb tree, and
+then clean it up later.
+
+However this only happens if we successfully start a transaction.  If
+we've aborted previously we will skip this step completely, and only
+have reloc roots with a reference count of 0, but were never properly
+removed from the reloc control's rb tree.
+
+This isn't a problem per-se, our references are held by the list the
+reloc roots are on, and by the original root the reloc root belongs to.
+If we end up in this situation all the reloc roots will be added to the
+dirty_reloc_list, and then properly dropped at that point.  The reloc
+control will be free'd and the rb tree is no longer used.
+
+There were two options when fixing this, one was to remove the BUG_ON(),
+the other was to make prepare_to_merge() handle the case where we
+couldn't start a trans handle.
+
+IMO this is the cleaner solution.  I started with handling the error in
+prepare_to_merge(), but it turned out super ugly.  And in the end this
+BUG_ON() simply doesn't matter, the cleanup was happening properly, we
+were just panicing because this BUG_ON() only matters in the success
+case.  So I've opted to just remove it and add a comment where it was.
+
+Reviewed-by: Qu Wenruo <wqu@suse.com>
+Signed-off-by: Josef Bacik <josef@toxicpanda.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/btrfs/relocation.c | 16 +++++++++++++++-
+ 1 file changed, 15 insertions(+), 1 deletion(-)
+
+diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
+index bc1d7f144ace9..7ce48f1364f76 100644
+--- a/fs/btrfs/relocation.c
++++ b/fs/btrfs/relocation.c
+@@ -2562,7 +2562,21 @@ out:
+                       free_reloc_roots(&reloc_roots);
+       }
+-      BUG_ON(!RB_EMPTY_ROOT(&rc->reloc_root_tree.rb_root));
++      /*
++       * We used to have
++       *
++       * BUG_ON(!RB_EMPTY_ROOT(&rc->reloc_root_tree.rb_root));
++       *
++       * here, but it's wrong.  If we fail to start the transaction in
++       * prepare_to_merge() we will have only 0 ref reloc roots, none of which
++       * have actually been removed from the reloc_root_tree rb tree.  This is
++       * fine because we're bailing here, and we hold a reference on the root
++       * for the list that holds it, so these roots will be cleaned up when we
++       * do the reloc_dirty_list afterwards.  Meanwhile the root->reloc_root
++       * will be cleaned up on unmount.
++       *
++       * The remaining nodes will be cleaned up by free_reloc_control.
++       */
+ }
+ static void free_block_list(struct rb_root *blocks)
+-- 
+2.20.1
+
diff --git a/queue-5.4/btrfs-restart-relocate_tree_blocks-properly.patch b/queue-5.4/btrfs-restart-relocate_tree_blocks-properly.patch
new file mode 100644 (file)
index 0000000..10b13e0
--- /dev/null
@@ -0,0 +1,70 @@
+From 7d2cef3b894c3ba222be007aa8f733f955786e1e Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 13 Mar 2020 17:17:07 -0400
+Subject: btrfs: restart relocate_tree_blocks properly
+
+From: Josef Bacik <josef@toxicpanda.com>
+
+[ Upstream commit 50dbbb71c79df89532ec41d118d59386e5a877e3 ]
+
+There are two bugs here, but fixing them independently would just result
+in pain if you happened to bisect between the two patches.
+
+First is how we handle the -EAGAIN from relocate_tree_block().  We don't
+set error, unless we happen to be the first node, which makes no sense,
+I have no idea what the code was trying to accomplish here.
+
+We in fact _do_ want err set here so that we know we need to restart in
+relocate_block_group().  Also we need finish_pending_nodes() to not
+actually call link_to_upper(), because we didn't actually relocate the
+block.
+
+And then if we do get -EAGAIN we do not want to set our backref cache
+last_trans to the one before ours.  This would force us to update our
+backref cache if we didn't cross transaction ids, which would mean we'd
+have some nodes updated to their new_bytenr, but still able to find
+their old bytenr because we're searching the same commit root as the
+last time we went through relocate_tree_blocks.
+
+Fixing these two things keeps us from panicing when we start breaking
+out of relocate_tree_blocks() either for delayed ref flushing or enospc.
+
+Signed-off-by: Josef Bacik <josef@toxicpanda.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/btrfs/relocation.c | 11 ++---------
+ 1 file changed, 2 insertions(+), 9 deletions(-)
+
+diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
+index 7ce48f1364f76..c4ed7015cc7d9 100644
+--- a/fs/btrfs/relocation.c
++++ b/fs/btrfs/relocation.c
+@@ -3176,9 +3176,8 @@ int relocate_tree_blocks(struct btrfs_trans_handle *trans,
+               ret = relocate_tree_block(trans, rc, node, &block->key,
+                                         path);
+               if (ret < 0) {
+-                      if (ret != -EAGAIN || &block->rb_node == rb_first(blocks))
+-                              err = ret;
+-                      goto out;
++                      err = ret;
++                      break;
+               }
+       }
+ out:
+@@ -4154,12 +4153,6 @@ restart:
+               if (!RB_EMPTY_ROOT(&blocks)) {
+                       ret = relocate_tree_blocks(trans, rc, &blocks);
+                       if (ret < 0) {
+-                              /*
+-                               * if we fail to relocate tree blocks, force to update
+-                               * backref cache when committing transaction.
+-                               */
+-                              rc->backref_cache.last_trans = trans->transid - 1;
+-
+                               if (ret != -EAGAIN) {
+                                       err = ret;
+                                       break;
+-- 
+2.20.1
+
diff --git a/queue-5.4/btrfs-track-reloc-roots-based-on-their-commit-root-b.patch b/queue-5.4/btrfs-track-reloc-roots-based-on-their-commit-root-b.patch
new file mode 100644 (file)
index 0000000..58dbbce
--- /dev/null
@@ -0,0 +1,121 @@
+From 1d3a3a28c28a62083bdcef54e778dad3d3e15be8 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 13 Mar 2020 17:17:08 -0400
+Subject: btrfs: track reloc roots based on their commit root bytenr
+
+From: Josef Bacik <josef@toxicpanda.com>
+
+[ Upstream commit ea287ab157c2816bf12aad4cece41372f9d146b4 ]
+
+We always search the commit root of the extent tree for looking up back
+references, however we track the reloc roots based on their current
+bytenr.
+
+This is wrong, if we commit the transaction between relocating tree
+blocks we could end up in this code in build_backref_tree
+
+  if (key.objectid == key.offset) {
+         /*
+          * Only root blocks of reloc trees use backref
+          * pointing to itself.
+          */
+         root = find_reloc_root(rc, cur->bytenr);
+         ASSERT(root);
+         cur->root = root;
+         break;
+  }
+
+find_reloc_root() is looking based on the bytenr we had in the commit
+root, but if we've COWed this reloc root we will not find that bytenr,
+and we will trip over the ASSERT(root).
+
+Fix this by using the commit_root->start bytenr for indexing the commit
+root.  Then we change the __update_reloc_root() caller to be used when
+we switch the commit root for the reloc root during commit.
+
+This fixes the panic I was seeing when we started throttling relocation
+for delayed refs.
+
+Signed-off-by: Josef Bacik <josef@toxicpanda.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/btrfs/relocation.c | 17 +++++++----------
+ 1 file changed, 7 insertions(+), 10 deletions(-)
+
+diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
+index c4ed7015cc7d9..cb4a888fc9dec 100644
+--- a/fs/btrfs/relocation.c
++++ b/fs/btrfs/relocation.c
+@@ -1298,7 +1298,7 @@ static int __must_check __add_reloc_root(struct btrfs_root *root)
+       if (!node)
+               return -ENOMEM;
+-      node->bytenr = root->node->start;
++      node->bytenr = root->commit_root->start;
+       node->data = root;
+       spin_lock(&rc->reloc_root_tree.lock);
+@@ -1329,10 +1329,11 @@ static void __del_reloc_root(struct btrfs_root *root)
+       if (rc && root->node) {
+               spin_lock(&rc->reloc_root_tree.lock);
+               rb_node = tree_search(&rc->reloc_root_tree.rb_root,
+-                                    root->node->start);
++                                    root->commit_root->start);
+               if (rb_node) {
+                       node = rb_entry(rb_node, struct mapping_node, rb_node);
+                       rb_erase(&node->rb_node, &rc->reloc_root_tree.rb_root);
++                      RB_CLEAR_NODE(&node->rb_node);
+               }
+               spin_unlock(&rc->reloc_root_tree.lock);
+               if (!node)
+@@ -1350,7 +1351,7 @@ static void __del_reloc_root(struct btrfs_root *root)
+  * helper to update the 'address of tree root -> reloc tree'
+  * mapping
+  */
+-static int __update_reloc_root(struct btrfs_root *root, u64 new_bytenr)
++static int __update_reloc_root(struct btrfs_root *root)
+ {
+       struct btrfs_fs_info *fs_info = root->fs_info;
+       struct rb_node *rb_node;
+@@ -1359,7 +1360,7 @@ static int __update_reloc_root(struct btrfs_root *root, u64 new_bytenr)
+       spin_lock(&rc->reloc_root_tree.lock);
+       rb_node = tree_search(&rc->reloc_root_tree.rb_root,
+-                            root->node->start);
++                            root->commit_root->start);
+       if (rb_node) {
+               node = rb_entry(rb_node, struct mapping_node, rb_node);
+               rb_erase(&node->rb_node, &rc->reloc_root_tree.rb_root);
+@@ -1371,7 +1372,7 @@ static int __update_reloc_root(struct btrfs_root *root, u64 new_bytenr)
+       BUG_ON((struct btrfs_root *)node->data != root);
+       spin_lock(&rc->reloc_root_tree.lock);
+-      node->bytenr = new_bytenr;
++      node->bytenr = root->node->start;
+       rb_node = tree_insert(&rc->reloc_root_tree.rb_root,
+                             node->bytenr, &node->rb_node);
+       spin_unlock(&rc->reloc_root_tree.lock);
+@@ -1529,6 +1530,7 @@ int btrfs_update_reloc_root(struct btrfs_trans_handle *trans,
+       }
+       if (reloc_root->commit_root != reloc_root->node) {
++              __update_reloc_root(reloc_root);
+               btrfs_set_root_node(root_item, reloc_root->node);
+               free_extent_buffer(reloc_root->commit_root);
+               reloc_root->commit_root = btrfs_root_node(reloc_root);
+@@ -4718,11 +4720,6 @@ int btrfs_reloc_cow_block(struct btrfs_trans_handle *trans,
+       BUG_ON(rc->stage == UPDATE_DATA_PTRS &&
+              root->root_key.objectid == BTRFS_DATA_RELOC_TREE_OBJECTID);
+-      if (root->root_key.objectid == BTRFS_TREE_RELOC_OBJECTID) {
+-              if (buf == root->node)
+-                      __update_reloc_root(root, cow->start);
+-      }
+-
+       level = btrfs_header_level(buf);
+       if (btrfs_header_generation(buf) <=
+           btrfs_root_last_snapshot(&root->root_item))
+-- 
+2.20.1
+
diff --git a/queue-5.4/bus-sunxi-rsb-return-correct-data-when-mixing-16-bit.patch b/queue-5.4/bus-sunxi-rsb-return-correct-data-when-mixing-16-bit.patch
new file mode 100644 (file)
index 0000000..a2f941a
--- /dev/null
@@ -0,0 +1,65 @@
+From c8366f70f9db20450b30aaa7b9d02069a6a4696b Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 21 Feb 2020 21:27:26 +0100
+Subject: bus: sunxi-rsb: Return correct data when mixing 16-bit and 8-bit
+ reads
+
+From: Ondrej Jirman <megous@megous.com>
+
+[ Upstream commit a43ab30dcd4a1abcdd0d2461bf1cf7c0817f6cd3 ]
+
+When doing a 16-bit read that returns data in the MSB byte, the
+RSB_DATA register will keep the MSB byte unchanged when doing
+the following 8-bit read. sunxi_rsb_read() will then return
+a result that contains high byte from 16-bit read mixed with
+the 8-bit result.
+
+The consequence is that after this happens the PMIC's regmap will
+look like this: (0x33 is the high byte from the 16-bit read)
+
+% cat /sys/kernel/debug/regmap/sunxi-rsb-3a3/registers
+00: 33
+01: 33
+02: 33
+03: 33
+04: 33
+05: 33
+06: 33
+07: 33
+08: 33
+09: 33
+0a: 33
+0b: 33
+0c: 33
+0d: 33
+0e: 33
+[snip]
+
+Fix this by masking the result of the read with the correct mask
+based on the size of the read. There are no 16-bit users in the
+mainline kernel, so this doesn't need to get into the stable tree.
+
+Signed-off-by: Ondrej Jirman <megous@megous.com>
+Acked-by: Chen-Yu Tsai <wens@csie.org>
+Signed-off-by: Maxime Ripard <maxime@cerno.tech>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/bus/sunxi-rsb.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/bus/sunxi-rsb.c b/drivers/bus/sunxi-rsb.c
+index be79d6c6a4e45..1bb00a959c67f 100644
+--- a/drivers/bus/sunxi-rsb.c
++++ b/drivers/bus/sunxi-rsb.c
+@@ -345,7 +345,7 @@ static int sunxi_rsb_read(struct sunxi_rsb *rsb, u8 rtaddr, u8 addr,
+       if (ret)
+               goto unlock;
+-      *buf = readl(rsb->regs + RSB_DATA);
++      *buf = readl(rsb->regs + RSB_DATA) & GENMASK(len * 8 - 1, 0);
+ unlock:
+       mutex_unlock(&rsb->lock);
+-- 
+2.20.1
+
diff --git a/queue-5.4/cfg80211-do-not-warn-on-same-channel-at-the-end-of-c.patch b/queue-5.4/cfg80211-do-not-warn-on-same-channel-at-the-end-of-c.patch
new file mode 100644 (file)
index 0000000..e50cb9f
--- /dev/null
@@ -0,0 +1,45 @@
+From bd4fb7844ba5d92caaadb38c0d691f898b06ccf1 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 26 Mar 2020 15:09:43 +0200
+Subject: cfg80211: Do not warn on same channel at the end of CSA
+
+From: Ilan Peer <ilan.peer@intel.com>
+
+[ Upstream commit 05dcb8bb258575a8dd3499d0d78bd2db633c2b23 ]
+
+When cfg80211_update_assoc_bss_entry() is called, there is a
+verification that the BSS channel actually changed. As some APs use
+CSA also for bandwidth changes, this would result with a kernel
+warning.
+
+Fix this by removing the WARN_ON().
+
+Signed-off-by: Ilan Peer <ilan.peer@intel.com>
+Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
+Link: https://lore.kernel.org/r/iwlwifi.20200326150855.96316ada0e8d.I6710376b1b4257e5f4712fc7ab16e2b638d512aa@changeid
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/wireless/scan.c | 6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+diff --git a/net/wireless/scan.c b/net/wireless/scan.c
+index aef240fdf8df6..328402ab64a3f 100644
+--- a/net/wireless/scan.c
++++ b/net/wireless/scan.c
+@@ -2022,7 +2022,11 @@ void cfg80211_update_assoc_bss_entry(struct wireless_dev *wdev,
+       spin_lock_bh(&rdev->bss_lock);
+-      if (WARN_ON(cbss->pub.channel == chan))
++      /*
++       * Some APs use CSA also for bandwidth changes, i.e., without actually
++       * changing the control channel, so no need to update in such a case.
++       */
++      if (cbss->pub.channel == chan)
+               goto done;
+       /* use transmitting bss */
+-- 
+2.20.1
+
diff --git a/queue-5.4/cpufreq-imx6q-fix-error-handling.patch b/queue-5.4/cpufreq-imx6q-fix-error-handling.patch
new file mode 100644 (file)
index 0000000..484c81f
--- /dev/null
@@ -0,0 +1,56 @@
+From 93caeccd730f9063ed49fd069434364cfbcceb4d Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 3 Mar 2020 10:14:49 +0800
+Subject: cpufreq: imx6q: fix error handling
+
+From: Peng Fan <peng.fan@nxp.com>
+
+[ Upstream commit 3646f50a3838c5949a89ecbdb868497cdc05b8fd ]
+
+When speed checking failed, direclty jumping to put_node label
+is not correct. Need jump to out_free_opp to avoid resources leak.
+
+Fixes: 2733fb0d0699 ("cpufreq: imx6q: read OCOTP through nvmem for imx6ul/imx6ull")
+Signed-off-by: Peng Fan <peng.fan@nxp.com>
+Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/cpufreq/imx6q-cpufreq.c | 9 +++++----
+ 1 file changed, 5 insertions(+), 4 deletions(-)
+
+diff --git a/drivers/cpufreq/imx6q-cpufreq.c b/drivers/cpufreq/imx6q-cpufreq.c
+index 1fcbbd53a48a2..edef3399c9794 100644
+--- a/drivers/cpufreq/imx6q-cpufreq.c
++++ b/drivers/cpufreq/imx6q-cpufreq.c
+@@ -381,23 +381,24 @@ static int imx6q_cpufreq_probe(struct platform_device *pdev)
+               goto put_reg;
+       }
++      /* Because we have added the OPPs here, we must free them */
++      free_opp = true;
++
+       if (of_machine_is_compatible("fsl,imx6ul") ||
+           of_machine_is_compatible("fsl,imx6ull")) {
+               ret = imx6ul_opp_check_speed_grading(cpu_dev);
+               if (ret) {
+                       if (ret == -EPROBE_DEFER)
+-                              goto put_node;
++                              goto out_free_opp;
+                       dev_err(cpu_dev, "failed to read ocotp: %d\n",
+                               ret);
+-                      goto put_node;
++                      goto out_free_opp;
+               }
+       } else {
+               imx6q_opp_check_speed_grading(cpu_dev);
+       }
+-      /* Because we have added the OPPs here, we must free them */
+-      free_opp = true;
+       num = dev_pm_opp_get_opp_count(cpu_dev);
+       if (num < 0) {
+               ret = num;
+-- 
+2.20.1
+
diff --git a/queue-5.4/cpufreq-imx6q-fixes-unwanted-cpu-overclocking-on-i.m.patch b/queue-5.4/cpufreq-imx6q-fixes-unwanted-cpu-overclocking-on-i.m.patch
new file mode 100644 (file)
index 0000000..a0ce801
--- /dev/null
@@ -0,0 +1,44 @@
+From b501c32d08d97ef54ae3cbb80a791d270f04d4ab Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 11 Feb 2020 12:58:07 +0100
+Subject: cpufreq: imx6q: Fixes unwanted cpu overclocking on i.MX6ULL
+
+From: Christoph Niedermaier <cniedermaier@dh-electronics.com>
+
+[ Upstream commit 36eb7dc1bd42fe5f850329c893768ff89b696fba ]
+
+imx6ul_opp_check_speed_grading is called for both i.MX6UL and i.MX6ULL.
+Since the i.MX6ULL was introduced to a separate ocotp compatible node
+later, it is possible that the i.MX6ULL has also dtbs with
+"fsl,imx6ull-ocotp". On a system without nvmem-cell speed grade a
+missing check on this node causes a driver fail without considering
+the cpu speed grade.
+
+This patch prevents unwanted cpu overclocking on i.MX6ULL with compatible
+node "fsl,imx6ull-ocotp" in old dtbs without nvmem-cell speed grade.
+
+Fixes: 2733fb0d0699 ("cpufreq: imx6q: read OCOTP through nvmem for imx6ul/imx6ull")
+Signed-off-by: Christoph Niedermaier <cniedermaier@dh-electronics.com>
+Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/cpufreq/imx6q-cpufreq.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/drivers/cpufreq/imx6q-cpufreq.c b/drivers/cpufreq/imx6q-cpufreq.c
+index 648a09a1778a3..1fcbbd53a48a2 100644
+--- a/drivers/cpufreq/imx6q-cpufreq.c
++++ b/drivers/cpufreq/imx6q-cpufreq.c
+@@ -280,6 +280,9 @@ static int imx6ul_opp_check_speed_grading(struct device *dev)
+               void __iomem *base;
+               np = of_find_compatible_node(NULL, NULL, "fsl,imx6ul-ocotp");
++              if (!np)
++                      np = of_find_compatible_node(NULL, NULL,
++                                                   "fsl,imx6ull-ocotp");
+               if (!np)
+                       return -ENOENT;
+-- 
+2.20.1
+
diff --git a/queue-5.4/cxgb4-ptp-pass-the-sign-of-offset-delta-in-fw-cmd.patch b/queue-5.4/cxgb4-ptp-pass-the-sign-of-offset-delta-in-fw-cmd.patch
new file mode 100644 (file)
index 0000000..62d3f85
--- /dev/null
@@ -0,0 +1,36 @@
+From b1deae0e8f228685fae3ed0d96ca56bd2c10b8e6 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 24 Mar 2020 17:10:00 +0530
+Subject: cxgb4/ptp: pass the sign of offset delta in FW CMD
+
+From: Raju Rangoju <rajur@chelsio.com>
+
+[ Upstream commit 50e0d28d3808146cc19b0d5564ef4ba9e5bf3846 ]
+
+cxgb4_ptp_fineadjtime() doesn't pass the signedness of offset delta
+in FW_PTP_CMD. Fix it by passing correct sign.
+
+Signed-off-by: Raju Rangoju <rajur@chelsio.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/chelsio/cxgb4/cxgb4_ptp.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_ptp.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_ptp.c
+index 58a039c3224ad..af1f40cbccc88 100644
+--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_ptp.c
++++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_ptp.c
+@@ -246,6 +246,9 @@ static int  cxgb4_ptp_fineadjtime(struct adapter *adapter, s64 delta)
+                            FW_PTP_CMD_PORTID_V(0));
+       c.retval_len16 = cpu_to_be32(FW_CMD_LEN16_V(sizeof(c) / 16));
+       c.u.ts.sc = FW_PTP_SC_ADJ_FTIME;
++      c.u.ts.sign = (delta < 0) ? 1 : 0;
++      if (delta < 0)
++              delta = -delta;
+       c.u.ts.tm = cpu_to_be64(delta);
+       err = t4_wr_mbox(adapter, adapter->mbox, &c, sizeof(c), NULL);
+-- 
+2.20.1
+
diff --git a/queue-5.4/debugfs-check-module-state-before-warning-in-full-op.patch b/queue-5.4/debugfs-check-module-state-before-warning-in-full-op.patch
new file mode 100644 (file)
index 0000000..41bf19a
--- /dev/null
@@ -0,0 +1,118 @@
+From 906b566171e4a0babb217f1b583e1e952f392e35 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 18 Feb 2020 04:31:50 +0000
+Subject: debugfs: Check module state before warning in
+ {full/open}_proxy_open()
+
+From: Taehee Yoo <ap420073@gmail.com>
+
+[ Upstream commit 275678e7a9be6a0ea9c1bb493e48abf2f4a01be5 ]
+
+When the module is being removed, the module state is set to
+MODULE_STATE_GOING. At this point, try_module_get() fails.
+And when {full/open}_proxy_open() is being called,
+it calls try_module_get() to try to hold module reference count.
+If it fails, it warns about the possibility of debugfs file leak.
+
+If {full/open}_proxy_open() is called while the module is being removed,
+it fails to hold the module.
+So, It warns about debugfs file leak. But it is not the debugfs file
+leak case. So, this patch just adds module state checking routine
+in the {full/open}_proxy_open().
+
+Test commands:
+    #SHELL1
+    while :
+    do
+        modprobe netdevsim
+        echo 1 > /sys/bus/netdevsim/new_device
+        modprobe -rv netdevsim
+    done
+
+    #SHELL2
+    while :
+    do
+        cat /sys/kernel/debug/netdevsim/netdevsim1/ports/0/ipsec
+    done
+
+Splat looks like:
+[  298.766738][T14664] debugfs file owner did not clean up at exit: ipsec
+[  298.766766][T14664] WARNING: CPU: 2 PID: 14664 at fs/debugfs/file.c:312 full_proxy_open+0x10f/0x650
+[  298.768595][T14664] Modules linked in: netdevsim(-) openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 n][  298.771343][T14664] CPU: 2 PID: 14664 Comm: cat Tainted: G        W         5.5.0+ #1
+[  298.772373][T14664] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
+[  298.773545][T14664] RIP: 0010:full_proxy_open+0x10f/0x650
+[  298.774247][T14664] Code: 48 c1 ea 03 80 3c 02 00 0f 85 c1 04 00 00 49 8b 3c 24 e8 e4 b5 78 ff 84 c0 75 2d 4c 89 ee 48
+[  298.776782][T14664] RSP: 0018:ffff88805b7df9b8 EFLAGS: 00010282[  298.777583][T14664] RAX: dffffc0000000008 RBX: ffff8880511725c0 RCX: 0000000000000000
+[  298.778610][T14664] RDX: 0000000000000000 RSI: 0000000000000006 RDI: ffff8880540c5c14
+[  298.779637][T14664] RBP: 0000000000000000 R08: fffffbfff15235ad R09: 0000000000000000
+[  298.780664][T14664] R10: 0000000000000001 R11: 0000000000000000 R12: ffffffffc06b5000
+[  298.781702][T14664] R13: ffff88804c234a88 R14: ffff88804c22dd00 R15: ffffffff8a1b5660
+[  298.782722][T14664] FS:  00007fafa13a8540(0000) GS:ffff88806c800000(0000) knlGS:0000000000000000
+[  298.783845][T14664] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+[  298.784672][T14664] CR2: 00007fafa0e9cd10 CR3: 000000004b286005 CR4: 00000000000606e0
+[  298.785739][T14664] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
+[  298.786769][T14664] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
+[  298.787785][T14664] Call Trace:
+[  298.788237][T14664]  do_dentry_open+0x63c/0xf50
+[  298.788872][T14664]  ? open_proxy_open+0x270/0x270
+[  298.789524][T14664]  ? __x64_sys_fchdir+0x180/0x180
+[  298.790169][T14664]  ? inode_permission+0x65/0x390
+[  298.790832][T14664]  path_openat+0xc45/0x2680
+[  298.791425][T14664]  ? save_stack+0x69/0x80
+[  298.791988][T14664]  ? save_stack+0x19/0x80
+[  298.792544][T14664]  ? path_mountpoint+0x2e0/0x2e0
+[  298.793233][T14664]  ? check_chain_key+0x236/0x5d0
+[  298.793910][T14664]  ? sched_clock_cpu+0x18/0x170
+[  298.794527][T14664]  ? find_held_lock+0x39/0x1d0
+[  298.795153][T14664]  do_filp_open+0x16a/0x260
+[ ... ]
+
+Fixes: 9fd4dcece43a ("debugfs: prevent access to possibly dead file_operations at file open")
+Reported-by: kbuild test robot <lkp@intel.com>
+Signed-off-by: Taehee Yoo <ap420073@gmail.com>
+Link: https://lore.kernel.org/r/20200218043150.29447-1-ap420073@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/debugfs/file.c | 18 ++++++++++++++----
+ 1 file changed, 14 insertions(+), 4 deletions(-)
+
+diff --git a/fs/debugfs/file.c b/fs/debugfs/file.c
+index 8fd45eb894243..b43960794922d 100644
+--- a/fs/debugfs/file.c
++++ b/fs/debugfs/file.c
+@@ -175,8 +175,13 @@ static int open_proxy_open(struct inode *inode, struct file *filp)
+       if (r)
+               goto out;
+-      real_fops = fops_get(real_fops);
+-      if (!real_fops) {
++      if (!fops_get(real_fops)) {
++#ifdef MODULE
++              if (real_fops->owner &&
++                  real_fops->owner->state == MODULE_STATE_GOING)
++                      goto out;
++#endif
++
+               /* Huh? Module did not clean up after itself at exit? */
+               WARN(1, "debugfs file owner did not clean up at exit: %pd",
+                       dentry);
+@@ -305,8 +310,13 @@ static int full_proxy_open(struct inode *inode, struct file *filp)
+       if (r)
+               goto out;
+-      real_fops = fops_get(real_fops);
+-      if (!real_fops) {
++      if (!fops_get(real_fops)) {
++#ifdef MODULE
++              if (real_fops->owner &&
++                  real_fops->owner->state == MODULE_STATE_GOING)
++                      goto out;
++#endif
++
+               /* Huh? Module did not cleanup after itself at exit? */
+               WARN(1, "debugfs file owner did not clean up at exit: %pd",
+                       dentry);
+-- 
+2.20.1
+
diff --git a/queue-5.4/dma-mapping-fix-dma_pgprot-for-unencrypted-coherent-.patch b/queue-5.4/dma-mapping-fix-dma_pgprot-for-unencrypted-coherent-.patch
new file mode 100644 (file)
index 0000000..1c7a23a
--- /dev/null
@@ -0,0 +1,47 @@
+From 95800ba4d41c6522f2aeef93975a3bbea626543b Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 4 Mar 2020 12:45:27 +0100
+Subject: dma-mapping: Fix dma_pgprot() for unencrypted coherent pages
+
+From: Thomas Hellstrom <thellstrom@vmware.com>
+
+[ Upstream commit 17c4a2ae15a7aaefe84bdb271952678c5c9cd8e1 ]
+
+When dma_mmap_coherent() sets up a mapping to unencrypted coherent memory
+under SEV encryption and sometimes under SME encryption, it will actually
+set up an encrypted mapping rather than an unencrypted, causing devices
+that DMAs from that memory to read encrypted contents. Fix this.
+
+When force_dma_unencrypted() returns true, the linear kernel map of the
+coherent pages have had the encryption bit explicitly cleared and the
+page content is unencrypted. Make sure that any additional PTEs we set
+up to these pages also have the encryption bit cleared by having
+dma_pgprot() return a protection with the encryption bit cleared in this
+case.
+
+Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
+Signed-off-by: Borislav Petkov <bp@suse.de>
+Reviewed-by: Christoph Hellwig <hch@lst.de>
+Acked-by: Tom Lendacky <thomas.lendacky@amd.com>
+Link: https://lkml.kernel.org/r/20200304114527.3636-3-thomas_os@shipmail.org
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ kernel/dma/mapping.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c
+index d9334f31a5afb..8682a5305cb36 100644
+--- a/kernel/dma/mapping.c
++++ b/kernel/dma/mapping.c
+@@ -169,6 +169,8 @@ EXPORT_SYMBOL(dma_get_sgtable_attrs);
+  */
+ pgprot_t dma_pgprot(struct device *dev, pgprot_t prot, unsigned long attrs)
+ {
++      if (force_dma_unencrypted(dev))
++              prot = pgprot_decrypted(prot);
+       if (dev_is_dma_coherent(dev) ||
+           (IS_ENABLED(CONFIG_DMA_NONCOHERENT_CACHE_SYNC) &&
+              (attrs & DMA_ATTR_NON_CONSISTENT)))
+-- 
+2.20.1
+
diff --git a/queue-5.4/drm-scheduler-fix-rare-null-ptr-race.patch b/queue-5.4/drm-scheduler-fix-rare-null-ptr-race.patch
new file mode 100644 (file)
index 0000000..e25b8f1
--- /dev/null
@@ -0,0 +1,77 @@
+From 10b09e307af9bbc3698c86138c433d6bbcc519d5 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 23 Mar 2020 19:19:37 +0800
+Subject: drm/scheduler: fix rare NULL ptr race
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Yintian Tao <yttao@amd.com>
+
+[ Upstream commit 77bb2f204f1f0a53a602a8fd15816d6826212077 ]
+
+There is one one corner case at dma_fence_signal_locked
+which will raise the NULL pointer problem just like below.
+->dma_fence_signal
+    ->dma_fence_signal_locked
+       ->test_and_set_bit
+here trigger dma_fence_release happen due to the zero of fence refcount.
+
+->dma_fence_put
+    ->dma_fence_release
+       ->drm_sched_fence_release_scheduled
+           ->call_rcu
+here make the union fled “cb_list” at finished fence
+to NULL because struct rcu_head contains two pointer
+which is same as struct list_head cb_list
+
+Therefore, to hold the reference of finished fence at drm_sched_process_job
+to prevent the null pointer during finished fence dma_fence_signal
+
+[  732.912867] BUG: kernel NULL pointer dereference, address: 0000000000000008
+[  732.914815] #PF: supervisor write access in kernel mode
+[  732.915731] #PF: error_code(0x0002) - not-present page
+[  732.916621] PGD 0 P4D 0
+[  732.917072] Oops: 0002 [#1] SMP PTI
+[  732.917682] CPU: 7 PID: 0 Comm: swapper/7 Tainted: G           OE     5.4.0-rc7 #1
+[  732.918980] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014
+[  732.920906] RIP: 0010:dma_fence_signal_locked+0x3e/0x100
+[  732.938569] Call Trace:
+[  732.939003]  <IRQ>
+[  732.939364]  dma_fence_signal+0x29/0x50
+[  732.940036]  drm_sched_fence_finished+0x12/0x20 [gpu_sched]
+[  732.940996]  drm_sched_process_job+0x34/0xa0 [gpu_sched]
+[  732.941910]  dma_fence_signal_locked+0x85/0x100
+[  732.942692]  dma_fence_signal+0x29/0x50
+[  732.943457]  amdgpu_fence_process+0x99/0x120 [amdgpu]
+[  732.944393]  sdma_v4_0_process_trap_irq+0x81/0xa0 [amdgpu]
+
+v2: hold the finished fence at drm_sched_process_job instead of
+    amdgpu_fence_process
+v3: resume the blank line
+
+Signed-off-by: Yintian Tao <yttao@amd.com>
+Reviewed-by: Christian König <christian.koenig@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/gpu/drm/scheduler/sched_main.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/drivers/gpu/drm/scheduler/sched_main.c b/drivers/gpu/drm/scheduler/sched_main.c
+index 2af64459b3d77..dfb29e6eeff1e 100644
+--- a/drivers/gpu/drm/scheduler/sched_main.c
++++ b/drivers/gpu/drm/scheduler/sched_main.c
+@@ -627,7 +627,9 @@ static void drm_sched_process_job(struct dma_fence *f, struct dma_fence_cb *cb)
+       trace_drm_sched_process_job(s_fence);
++      dma_fence_get(&s_fence->finished);
+       drm_sched_fence_finished(s_fence);
++      dma_fence_put(&s_fence->finished);
+       wake_up_interruptible(&sched->wake_up_worker);
+ }
+-- 
+2.20.1
+
diff --git a/queue-5.4/efi-x86-ignore-the-memory-attributes-table-on-i386.patch b/queue-5.4/efi-x86-ignore-the-memory-attributes-table-on-i386.patch
new file mode 100644 (file)
index 0000000..16a01b1
--- /dev/null
@@ -0,0 +1,77 @@
+From a1d390a178c982e901325067a6f39f2c70d7036c Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 8 Mar 2020 09:08:51 +0100
+Subject: efi/x86: Ignore the memory attributes table on i386
+
+From: Ard Biesheuvel <ardb@kernel.org>
+
+[ Upstream commit dd09fad9d2caad2325a39b766ce9e79cfc690184 ]
+
+Commit:
+
+  3a6b6c6fb23667fa ("efi: Make EFI_MEMORY_ATTRIBUTES_TABLE initialization common across all architectures")
+
+moved the call to efi_memattr_init() from ARM specific to the generic
+EFI init code, in order to be able to apply the restricted permissions
+described in that table on x86 as well.
+
+We never enabled this feature fully on i386, and so mapping and
+reserving this table is pointless. However, due to the early call to
+memblock_reserve(), the memory bookkeeping gets confused to the point
+where it produces the splat below when we try to map the memory later
+on:
+
+  ------------[ cut here ]------------
+  ioremap on RAM at 0x3f251000 - 0x3fa1afff
+  WARNING: CPU: 0 PID: 0 at arch/x86/mm/ioremap.c:166 __ioremap_caller ...
+  Modules linked in:
+  CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.20.0 #48
+  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015
+  EIP: __ioremap_caller.constprop.0+0x249/0x260
+  Code: 90 0f b7 05 4e 38 40 de 09 45 e0 e9 09 ff ff ff 90 8d 45 ec c6 05 ...
+  EAX: 00000029 EBX: 00000000 ECX: de59c228 EDX: 00000001
+  ESI: 3f250fff EDI: 00000000 EBP: de3edf20 ESP: de3edee0
+  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00200296
+  CR0: 80050033 CR2: ffd17000 CR3: 1e58c000 CR4: 00040690
+  Call Trace:
+   ioremap_cache+0xd/0x10
+   ? old_map_region+0x72/0x9d
+   old_map_region+0x72/0x9d
+   efi_map_region+0x8/0xa
+   efi_enter_virtual_mode+0x260/0x43b
+   start_kernel+0x329/0x3aa
+   i386_start_kernel+0xa7/0xab
+   startup_32_smp+0x164/0x168
+  ---[ end trace e15ccf6b9f356833 ]---
+
+Let's work around this by disregarding the memory attributes table
+altogether on i386, which does not result in a loss of functionality
+or protection, given that we never consumed the contents.
+
+Fixes: 3a6b6c6fb23667fa ("efi: Make EFI_MEMORY_ATTRIBUTES_TABLE ... ")
+Tested-by: Arvind Sankar <nivedita@alum.mit.edu>
+Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Link: https://lore.kernel.org/r/20200304165917.5893-1-ardb@kernel.org
+Link: https://lore.kernel.org/r/20200308080859.21568-21-ardb@kernel.org
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/firmware/efi/efi.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
+index ad8a4bc074fbf..e3861d267d9aa 100644
+--- a/drivers/firmware/efi/efi.c
++++ b/drivers/firmware/efi/efi.c
+@@ -562,7 +562,7 @@ int __init efi_config_parse_tables(void *config_tables, int count, int sz,
+               }
+       }
+-      if (efi_enabled(EFI_MEMMAP))
++      if (!IS_ENABLED(CONFIG_X86_32) && efi_enabled(EFI_MEMMAP))
+               efi_memattr_init();
+       efi_tpm_eventlog_init();
+-- 
+2.20.1
+
diff --git a/queue-5.4/firmware-arm_sdei-fix-double-lock-on-hibernate-with-.patch b/queue-5.4/firmware-arm_sdei-fix-double-lock-on-hibernate-with-.patch
new file mode 100644 (file)
index 0000000..f5583e6
--- /dev/null
@@ -0,0 +1,118 @@
+From 09e9c391156578f4acab942279fb6eeabe8425b6 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 21 Feb 2020 16:35:06 +0000
+Subject: firmware: arm_sdei: fix double-lock on hibernate with shared events
+
+From: James Morse <james.morse@arm.com>
+
+[ Upstream commit 6ded0b61cf638bf9f8efe60ab8ba23db60ea9763 ]
+
+SDEI has private events that must be registered on each CPU. When
+CPUs come and go they must re-register and re-enable their private
+events. Each event has flags to indicate whether this should happen
+to protect against an event being registered on a CPU coming online,
+while all the others are unregistering the event.
+
+These flags are protected by the sdei_list_lock spinlock, because
+the cpuhp callbacks can't take the mutex.
+
+Hibernate needs to unregister all events, but keep the in-memory
+re-register and re-enable as they are. sdei_unregister_shared()
+takes the spinlock to walk the list, then calls _sdei_event_unregister()
+on each shared event. _sdei_event_unregister() tries to take the
+same spinlock to update re-register and re-enable. This doesn't go
+so well.
+
+Push the re-register and re-enable updates out to their callers.
+sdei_unregister_shared() doesn't want these values updated, so
+doesn't need to do anything.
+
+This also fixes shared events getting lost over hibernate as this
+path made them look unregistered.
+
+Fixes: da351827240e ("firmware: arm_sdei: Add support for CPU and system power states")
+Reported-by: Liguang Zhang <zhangliguang@linux.alibaba.com>
+Signed-off-by: James Morse <james.morse@arm.com>
+Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/firmware/arm_sdei.c | 32 +++++++++++++++-----------------
+ 1 file changed, 15 insertions(+), 17 deletions(-)
+
+diff --git a/drivers/firmware/arm_sdei.c b/drivers/firmware/arm_sdei.c
+index 9cd70d1a56221..eb2df89d4924f 100644
+--- a/drivers/firmware/arm_sdei.c
++++ b/drivers/firmware/arm_sdei.c
+@@ -491,11 +491,6 @@ static int _sdei_event_unregister(struct sdei_event *event)
+ {
+       lockdep_assert_held(&sdei_events_lock);
+-      spin_lock(&sdei_list_lock);
+-      event->reregister = false;
+-      event->reenable = false;
+-      spin_unlock(&sdei_list_lock);
+-
+       if (event->type == SDEI_EVENT_TYPE_SHARED)
+               return sdei_api_event_unregister(event->event_num);
+@@ -518,6 +513,11 @@ int sdei_event_unregister(u32 event_num)
+                       break;
+               }
++              spin_lock(&sdei_list_lock);
++              event->reregister = false;
++              event->reenable = false;
++              spin_unlock(&sdei_list_lock);
++
+               err = _sdei_event_unregister(event);
+               if (err)
+                       break;
+@@ -585,26 +585,15 @@ static int _sdei_event_register(struct sdei_event *event)
+       lockdep_assert_held(&sdei_events_lock);
+-      spin_lock(&sdei_list_lock);
+-      event->reregister = true;
+-      spin_unlock(&sdei_list_lock);
+-
+       if (event->type == SDEI_EVENT_TYPE_SHARED)
+               return sdei_api_event_register(event->event_num,
+                                              sdei_entry_point,
+                                              event->registered,
+                                              SDEI_EVENT_REGISTER_RM_ANY, 0);
+-
+       err = sdei_do_cross_call(_local_event_register, event);
+-      if (err) {
+-              spin_lock(&sdei_list_lock);
+-              event->reregister = false;
+-              event->reenable = false;
+-              spin_unlock(&sdei_list_lock);
+-
++      if (err)
+               sdei_do_cross_call(_local_event_unregister, event);
+-      }
+       return err;
+ }
+@@ -632,8 +621,17 @@ int sdei_event_register(u32 event_num, sdei_event_callback *cb, void *arg)
+                       break;
+               }
++              spin_lock(&sdei_list_lock);
++              event->reregister = true;
++              spin_unlock(&sdei_list_lock);
++
+               err = _sdei_event_register(event);
+               if (err) {
++                      spin_lock(&sdei_list_lock);
++                      event->reregister = false;
++                      event->reenable = false;
++                      spin_unlock(&sdei_list_lock);
++
+                       sdei_event_destroy(event);
+                       pr_warn("Failed to register event %u: %d\n", event_num,
+                               err);
+-- 
+2.20.1
+
diff --git a/queue-5.4/firmware-fix-a-double-abort-case-with-fw_load_sysfs_.patch b/queue-5.4/firmware-fix-a-double-abort-case-with-fw_load_sysfs_.patch
new file mode 100644 (file)
index 0000000..7b2230d
--- /dev/null
@@ -0,0 +1,81 @@
+From 170053ab85d178c182800a938c548c6bde3611f4 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 3 Mar 2020 10:36:08 +0800
+Subject: firmware: fix a double abort case with fw_load_sysfs_fallback
+
+From: Junyong Sun <sunjy516@gmail.com>
+
+[ Upstream commit bcfbd3523f3c6eea51a74d217a8ebc5463bcb7f4 ]
+
+fw_sysfs_wait_timeout may return err with -ENOENT
+at fw_load_sysfs_fallback and firmware is already
+in abort status, no need to abort again, so skip it.
+
+This issue is caused by concurrent situation like below:
+when thread 1# wait firmware loading, thread 2# may write
+-1 to abort loading and wakeup thread 1# before it timeout.
+so wait_for_completion_killable_timeout of thread 1# would
+return remaining time which is != 0 with fw_st->status
+FW_STATUS_ABORTED.And the results would be converted into
+err -ENOENT in __fw_state_wait_common and transfered to
+fw_load_sysfs_fallback in thread 1#.
+The -ENOENT means firmware status is already at ABORTED,
+so fw_load_sysfs_fallback no need to get mutex to abort again.
+-----------------------------
+thread 1#,wait for loading
+fw_load_sysfs_fallback
+ ->fw_sysfs_wait_timeout
+    ->__fw_state_wait_common
+       ->wait_for_completion_killable_timeout
+
+in __fw_state_wait_common,
+...
+93    ret = wait_for_completion_killable_timeout(&fw_st->completion, timeout);
+94    if (ret != 0 && fw_st->status == FW_STATUS_ABORTED)
+95       return -ENOENT;
+96    if (!ret)
+97      return -ETIMEDOUT;
+98
+99    return ret < 0 ? ret : 0;
+-----------------------------
+thread 2#, write -1 to abort loading
+firmware_loading_store
+ ->fw_load_abort
+   ->__fw_load_abort
+     ->fw_state_aborted
+       ->__fw_state_set
+         ->complete_all
+
+in __fw_state_set,
+...
+111    if (status == FW_STATUS_DONE || status == FW_STATUS_ABORTED)
+112       complete_all(&fw_st->completion);
+-------------------------------------------
+BTW,the double abort issue would not cause kernel panic or create an issue,
+but slow down it sometimes.The change is just a minor optimization.
+
+Signed-off-by: Junyong Sun <sunjunyong@xiaomi.com>
+Acked-by: Luis Chamberlain <mcgrof@kernel.org>
+Link: https://lore.kernel.org/r/1583202968-28792-1-git-send-email-sunjunyong@xiaomi.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/base/firmware_loader/fallback.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/base/firmware_loader/fallback.c b/drivers/base/firmware_loader/fallback.c
+index 62ee90b4db56e..70efbb22dfc30 100644
+--- a/drivers/base/firmware_loader/fallback.c
++++ b/drivers/base/firmware_loader/fallback.c
+@@ -525,7 +525,7 @@ static int fw_load_sysfs_fallback(struct fw_sysfs *fw_sysfs,
+       }
+       retval = fw_sysfs_wait_timeout(fw_priv, timeout);
+-      if (retval < 0) {
++      if (retval < 0 && retval != -ENOENT) {
+               mutex_lock(&fw_lock);
+               fw_load_abort(fw_sysfs);
+               mutex_unlock(&fw_lock);
+-- 
+2.20.1
+
diff --git a/queue-5.4/genirq-irqdomain-check-pointer-in-irq_domain_alloc_i.patch b/queue-5.4/genirq-irqdomain-check-pointer-in-irq_domain_alloc_i.patch
new file mode 100644 (file)
index 0000000..983666b
--- /dev/null
@@ -0,0 +1,66 @@
+From efb6c6ba898c018ca0d57b368338172b01f55de6 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 6 Mar 2020 18:47:20 +0100
+Subject: genirq/irqdomain: Check pointer in irq_domain_alloc_irqs_hierarchy()
+
+From: Alexander Sverdlin <alexander.sverdlin@nokia.com>
+
+[ Upstream commit 87f2d1c662fa1761359fdf558246f97e484d177a ]
+
+irq_domain_alloc_irqs_hierarchy() has 3 call sites in the compilation unit
+but only one of them checks for the pointer which is being dereferenced
+inside the called function. Move the check into the function. This allows
+for catching the error instead of the following crash:
+
+Unable to handle kernel NULL pointer dereference at virtual address 00000000
+PC is at 0x0
+LR is at gpiochip_hierarchy_irq_domain_alloc+0x11f/0x140
+...
+[<c06c23ff>] (gpiochip_hierarchy_irq_domain_alloc)
+[<c0462a89>] (__irq_domain_alloc_irqs)
+[<c0462dad>] (irq_create_fwspec_mapping)
+[<c06c2251>] (gpiochip_to_irq)
+[<c06c1c9b>] (gpiod_to_irq)
+[<bf973073>] (gpio_irqs_init [gpio_irqs])
+[<bf974048>] (gpio_irqs_exit+0xecc/0xe84 [gpio_irqs])
+Code: bad PC value
+
+Signed-off-by: Alexander Sverdlin <alexander.sverdlin@nokia.com>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Link: https://lkml.kernel.org/r/20200306174720.82604-1-alexander.sverdlin@nokia.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ kernel/irq/irqdomain.c | 10 +++++-----
+ 1 file changed, 5 insertions(+), 5 deletions(-)
+
+diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
+index 480df36597206..c776b8e86fbcc 100644
+--- a/kernel/irq/irqdomain.c
++++ b/kernel/irq/irqdomain.c
+@@ -1293,6 +1293,11 @@ int irq_domain_alloc_irqs_hierarchy(struct irq_domain *domain,
+                                   unsigned int irq_base,
+                                   unsigned int nr_irqs, void *arg)
+ {
++      if (!domain->ops->alloc) {
++              pr_debug("domain->ops->alloc() is NULL\n");
++              return -ENOSYS;
++      }
++
+       return domain->ops->alloc(domain, irq_base, nr_irqs, arg);
+ }
+@@ -1330,11 +1335,6 @@ int __irq_domain_alloc_irqs(struct irq_domain *domain, int irq_base,
+                       return -EINVAL;
+       }
+-      if (!domain->ops->alloc) {
+-              pr_debug("domain->ops->alloc() is NULL\n");
+-              return -ENOSYS;
+-      }
+-
+       if (realloc && irq_base >= 0) {
+               virq = irq_base;
+       } else {
+-- 
+2.20.1
+
diff --git a/queue-5.4/gfs2-do-log_flush-in-gfs2_ail_empty_gl-even-if-ail-l.patch b/queue-5.4/gfs2-do-log_flush-in-gfs2_ail_empty_gl-even-if-ail-l.patch
new file mode 100644 (file)
index 0000000..292967b
--- /dev/null
@@ -0,0 +1,109 @@
+From b84fee9b225437c7a78a445f9fd72d03a8e19243 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 13 Nov 2019 13:47:02 -0600
+Subject: gfs2: Do log_flush in gfs2_ail_empty_gl even if ail list is empty
+
+From: Bob Peterson <rpeterso@redhat.com>
+
+[ Upstream commit 9ff78289356af640941bbb0dd3f46af2063f0046 ]
+
+Before this patch, if gfs2_ail_empty_gl saw there was nothing on
+the ail list, it would return and not flush the log. The problem
+is that there could still be a revoke for the rgrp sitting on the
+sd_log_le_revoke list that's been recently taken off the ail list.
+But that revoke still needs to be written, and the rgrp_go_inval
+still needs to call log_flush_wait to ensure the revokes are all
+properly written to the journal before we relinquish control of
+the glock to another node. If we give the glock to another node
+before we have this knowledge, the node might crash and its journal
+replayed, in which case the missing revoke would allow the journal
+replay to replay the rgrp over top of the rgrp we already gave to
+another node, thus overwriting its changes and corrupting the
+file system.
+
+This patch makes gfs2_ail_empty_gl still call gfs2_log_flush rather
+than returning.
+
+Signed-off-by: Bob Peterson <rpeterso@redhat.com>
+Reviewed-by: Andreas Gruenbacher <agruenba@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/gfs2/glops.c | 27 ++++++++++++++++++++++++++-
+ fs/gfs2/log.c   |  2 +-
+ fs/gfs2/log.h   |  1 +
+ 3 files changed, 28 insertions(+), 2 deletions(-)
+
+diff --git a/fs/gfs2/glops.c b/fs/gfs2/glops.c
+index ff213690e3648..83cf64da474cb 100644
+--- a/fs/gfs2/glops.c
++++ b/fs/gfs2/glops.c
+@@ -89,8 +89,32 @@ static void gfs2_ail_empty_gl(struct gfs2_glock *gl)
+       INIT_LIST_HEAD(&tr.tr_databuf);
+       tr.tr_revokes = atomic_read(&gl->gl_ail_count);
+-      if (!tr.tr_revokes)
++      if (!tr.tr_revokes) {
++              bool have_revokes;
++              bool log_in_flight;
++
++              /*
++               * We have nothing on the ail, but there could be revokes on
++               * the sdp revoke queue, in which case, we still want to flush
++               * the log and wait for it to finish.
++               *
++               * If the sdp revoke list is empty too, we might still have an
++               * io outstanding for writing revokes, so we should wait for
++               * it before returning.
++               *
++               * If none of these conditions are true, our revokes are all
++               * flushed and we can return.
++               */
++              gfs2_log_lock(sdp);
++              have_revokes = !list_empty(&sdp->sd_log_revokes);
++              log_in_flight = atomic_read(&sdp->sd_log_in_flight);
++              gfs2_log_unlock(sdp);
++              if (have_revokes)
++                      goto flush;
++              if (log_in_flight)
++                      log_flush_wait(sdp);
+               return;
++      }
+       /* A shortened, inline version of gfs2_trans_begin()
+          * tr->alloced is not set since the transaction structure is
+@@ -105,6 +129,7 @@ static void gfs2_ail_empty_gl(struct gfs2_glock *gl)
+       __gfs2_ail_flush(gl, 0, tr.tr_revokes);
+       gfs2_trans_end(sdp);
++flush:
+       gfs2_log_flush(sdp, NULL, GFS2_LOG_HEAD_FLUSH_NORMAL |
+                      GFS2_LFC_AIL_EMPTY_GL);
+ }
+diff --git a/fs/gfs2/log.c b/fs/gfs2/log.c
+index 2aed73666a657..47bc27d4169e6 100644
+--- a/fs/gfs2/log.c
++++ b/fs/gfs2/log.c
+@@ -513,7 +513,7 @@ static void log_pull_tail(struct gfs2_sbd *sdp, unsigned int new_tail)
+ }
+-static void log_flush_wait(struct gfs2_sbd *sdp)
++void log_flush_wait(struct gfs2_sbd *sdp)
+ {
+       DEFINE_WAIT(wait);
+diff --git a/fs/gfs2/log.h b/fs/gfs2/log.h
+index c762da4945468..52b9bf27e918f 100644
+--- a/fs/gfs2/log.h
++++ b/fs/gfs2/log.h
+@@ -73,6 +73,7 @@ extern void gfs2_log_flush(struct gfs2_sbd *sdp, struct gfs2_glock *gl,
+                          u32 type);
+ extern void gfs2_log_commit(struct gfs2_sbd *sdp, struct gfs2_trans *trans);
+ extern void gfs2_ail1_flush(struct gfs2_sbd *sdp, struct writeback_control *wbc);
++extern void log_flush_wait(struct gfs2_sbd *sdp);
+ extern void gfs2_log_shutdown(struct gfs2_sbd *sdp);
+ extern int gfs2_logd(void *data);
+-- 
+2.20.1
+
diff --git a/queue-5.4/gfs2-don-t-demote-a-glock-until-its-revokes-are-writ.patch b/queue-5.4/gfs2-don-t-demote-a-glock-until-its-revokes-are-writ.patch
new file mode 100644 (file)
index 0000000..60dba35
--- /dev/null
@@ -0,0 +1,46 @@
+From 6542d310f27bc4dca984e065e9b18939188032e4 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 13 Nov 2019 14:08:45 -0600
+Subject: gfs2: Don't demote a glock until its revokes are written
+
+From: Bob Peterson <rpeterso@redhat.com>
+
+[ Upstream commit df5db5f9ee112e76b5202fbc331f990a0fc316d6 ]
+
+Before this patch, run_queue would demote glocks based on whether
+there are any more holders. But if the glock has pending revokes that
+haven't been written to the media, giving up the glock might end in
+file system corruption if the revokes never get written due to
+io errors, node crashes and fences, etc. In that case, another node
+will replay the metadata blocks associated with the glock, but
+because the revoke was never written, it could replay that block
+even though the glock had since been granted to another node who
+might have made changes.
+
+This patch changes the logic in run_queue so that it never demotes
+a glock until its count of pending revokes reaches zero.
+
+Signed-off-by: Bob Peterson <rpeterso@redhat.com>
+Reviewed-by: Andreas Gruenbacher <agruenba@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/gfs2/glock.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/fs/gfs2/glock.c b/fs/gfs2/glock.c
+index 0290a22ebccf5..21820a5b388fd 100644
+--- a/fs/gfs2/glock.c
++++ b/fs/gfs2/glock.c
+@@ -639,6 +639,9 @@ __acquires(&gl->gl_lockref.lock)
+                       goto out_unlock;
+               if (nonblock)
+                       goto out_sched;
++              smp_mb();
++              if (atomic_read(&gl->gl_revokes) != 0)
++                      goto out_sched;
+               set_bit(GLF_DEMOTE_IN_PROGRESS, &gl->gl_flags);
+               GLOCK_BUG_ON(gl, gl->gl_demote_state == LM_ST_EXCLUSIVE);
+               gl->gl_target = gl->gl_demote_state;
+-- 
+2.20.1
+
diff --git a/queue-5.4/hinic-fix-a-bug-of-waitting-for-io-stopped.patch b/queue-5.4/hinic-fix-a-bug-of-waitting-for-io-stopped.patch
new file mode 100644 (file)
index 0000000..5bbd456
--- /dev/null
@@ -0,0 +1,92 @@
+From 97350b891e249edd4af0759478597f06f1515ce3 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 20 Mar 2020 23:13:16 +0000
+Subject: hinic: fix a bug of waitting for IO stopped
+
+From: Luo bin <luobin9@huawei.com>
+
+[ Upstream commit 96758117dc528e6d84bd23d205e8cf7f31eda029 ]
+
+it's unreliable for fw to check whether IO is stopped, so driver
+wait for enough time to ensure IO process is done in hw before
+freeing resources
+
+Signed-off-by: Luo bin <luobin9@huawei.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ .../net/ethernet/huawei/hinic/hinic_hw_dev.c  | 51 +------------------
+ 1 file changed, 2 insertions(+), 49 deletions(-)
+
+diff --git a/drivers/net/ethernet/huawei/hinic/hinic_hw_dev.c b/drivers/net/ethernet/huawei/hinic/hinic_hw_dev.c
+index 79b3d53f2fbfa..c7c75b772a866 100644
+--- a/drivers/net/ethernet/huawei/hinic/hinic_hw_dev.c
++++ b/drivers/net/ethernet/huawei/hinic/hinic_hw_dev.c
+@@ -360,50 +360,6 @@ static int wait_for_db_state(struct hinic_hwdev *hwdev)
+       return -EFAULT;
+ }
+-static int wait_for_io_stopped(struct hinic_hwdev *hwdev)
+-{
+-      struct hinic_cmd_io_status cmd_io_status;
+-      struct hinic_hwif *hwif = hwdev->hwif;
+-      struct pci_dev *pdev = hwif->pdev;
+-      struct hinic_pfhwdev *pfhwdev;
+-      unsigned long end;
+-      u16 out_size;
+-      int err;
+-
+-      if (!HINIC_IS_PF(hwif) && !HINIC_IS_PPF(hwif)) {
+-              dev_err(&pdev->dev, "Unsupported PCI Function type\n");
+-              return -EINVAL;
+-      }
+-
+-      pfhwdev = container_of(hwdev, struct hinic_pfhwdev, hwdev);
+-
+-      cmd_io_status.func_idx = HINIC_HWIF_FUNC_IDX(hwif);
+-
+-      end = jiffies + msecs_to_jiffies(IO_STATUS_TIMEOUT);
+-      do {
+-              err = hinic_msg_to_mgmt(&pfhwdev->pf_to_mgmt, HINIC_MOD_COMM,
+-                                      HINIC_COMM_CMD_IO_STATUS_GET,
+-                                      &cmd_io_status, sizeof(cmd_io_status),
+-                                      &cmd_io_status, &out_size,
+-                                      HINIC_MGMT_MSG_SYNC);
+-              if ((err) || (out_size != sizeof(cmd_io_status))) {
+-                      dev_err(&pdev->dev, "Failed to get IO status, ret = %d\n",
+-                              err);
+-                      return err;
+-              }
+-
+-              if (cmd_io_status.status == IO_STOPPED) {
+-                      dev_info(&pdev->dev, "IO stopped\n");
+-                      return 0;
+-              }
+-
+-              msleep(20);
+-      } while (time_before(jiffies, end));
+-
+-      dev_err(&pdev->dev, "Wait for IO stopped - Timeout\n");
+-      return -ETIMEDOUT;
+-}
+-
+ /**
+  * clear_io_resource - set the IO resources as not active in the NIC
+  * @hwdev: the NIC HW device
+@@ -423,11 +379,8 @@ static int clear_io_resources(struct hinic_hwdev *hwdev)
+               return -EINVAL;
+       }
+-      err = wait_for_io_stopped(hwdev);
+-      if (err) {
+-              dev_err(&pdev->dev, "IO has not stopped yet\n");
+-              return err;
+-      }
++      /* sleep 100ms to wait for firmware stopping I/O */
++      msleep(100);
+       cmd_clear_io_res.func_idx = HINIC_HWIF_FUNC_IDX(hwif);
+-- 
+2.20.1
+
diff --git a/queue-5.4/hinic-fix-out-of-order-excution-in-arm-cpu.patch b/queue-5.4/hinic-fix-out-of-order-excution-in-arm-cpu.patch
new file mode 100644 (file)
index 0000000..7437c1d
--- /dev/null
@@ -0,0 +1,79 @@
+From 73042ab6a4d5b691c7ce2dead0b32b21ae44e75b Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 20 Mar 2020 23:13:18 +0000
+Subject: hinic: fix out-of-order excution in arm cpu
+
+From: Luo bin <luobin9@huawei.com>
+
+[ Upstream commit 33f15da216a1f4566b4ec880942556ace30615df ]
+
+add read barrier in driver code to keep from reading other fileds
+in dma memory which is writable for hw until we have verified the
+memory is valid for driver
+
+Signed-off-by: Luo bin <luobin9@huawei.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/huawei/hinic/hinic_hw_cmdq.c | 2 ++
+ drivers/net/ethernet/huawei/hinic/hinic_hw_eqs.c  | 2 ++
+ drivers/net/ethernet/huawei/hinic/hinic_rx.c      | 3 +++
+ drivers/net/ethernet/huawei/hinic/hinic_tx.c      | 2 ++
+ 4 files changed, 9 insertions(+)
+
+diff --git a/drivers/net/ethernet/huawei/hinic/hinic_hw_cmdq.c b/drivers/net/ethernet/huawei/hinic/hinic_hw_cmdq.c
+index eb53c15b13f33..33f93cc25193a 100644
+--- a/drivers/net/ethernet/huawei/hinic/hinic_hw_cmdq.c
++++ b/drivers/net/ethernet/huawei/hinic/hinic_hw_cmdq.c
+@@ -623,6 +623,8 @@ static int cmdq_cmd_ceq_handler(struct hinic_cmdq *cmdq, u16 ci,
+       if (!CMDQ_WQE_COMPLETED(be32_to_cpu(ctrl->ctrl_info)))
+               return -EBUSY;
++      dma_rmb();
++
+       errcode = CMDQ_WQE_ERRCODE_GET(be32_to_cpu(status->status_info), VAL);
+       cmdq_sync_cmd_handler(cmdq, ci, errcode);
+diff --git a/drivers/net/ethernet/huawei/hinic/hinic_hw_eqs.c b/drivers/net/ethernet/huawei/hinic/hinic_hw_eqs.c
+index 6a723c4757bce..c0b6bcb067cd4 100644
+--- a/drivers/net/ethernet/huawei/hinic/hinic_hw_eqs.c
++++ b/drivers/net/ethernet/huawei/hinic/hinic_hw_eqs.c
+@@ -235,6 +235,8 @@ static void aeq_irq_handler(struct hinic_eq *eq)
+               if (HINIC_EQ_ELEM_DESC_GET(aeqe_desc, WRAPPED) == eq->wrapped)
+                       break;
++              dma_rmb();
++
+               event = HINIC_EQ_ELEM_DESC_GET(aeqe_desc, TYPE);
+               if (event >= HINIC_MAX_AEQ_EVENTS) {
+                       dev_err(&pdev->dev, "Unknown AEQ Event %d\n", event);
+diff --git a/drivers/net/ethernet/huawei/hinic/hinic_rx.c b/drivers/net/ethernet/huawei/hinic/hinic_rx.c
+index 2695ad69fca60..815649e37cb15 100644
+--- a/drivers/net/ethernet/huawei/hinic/hinic_rx.c
++++ b/drivers/net/ethernet/huawei/hinic/hinic_rx.c
+@@ -350,6 +350,9 @@ static int rxq_recv(struct hinic_rxq *rxq, int budget)
+               if (!rq_wqe)
+                       break;
++              /* make sure we read rx_done before packet length */
++              dma_rmb();
++
+               cqe = rq->cqe[ci];
+               status =  be32_to_cpu(cqe->status);
+               hinic_rq_get_sge(rxq->rq, rq_wqe, ci, &sge);
+diff --git a/drivers/net/ethernet/huawei/hinic/hinic_tx.c b/drivers/net/ethernet/huawei/hinic/hinic_tx.c
+index 0e13d1c7e4746..375d81d03e866 100644
+--- a/drivers/net/ethernet/huawei/hinic/hinic_tx.c
++++ b/drivers/net/ethernet/huawei/hinic/hinic_tx.c
+@@ -622,6 +622,8 @@ static int free_tx_poll(struct napi_struct *napi, int budget)
+       do {
+               hw_ci = HW_CONS_IDX(sq) & wq->mask;
++              dma_rmb();
++
+               /* Reading a WQEBB to get real WQE size and consumer index. */
+               sq_wqe = hinic_sq_read_wqebb(sq, &skb, &wqe_size, &sw_ci);
+               if ((!sq_wqe) ||
+-- 
+2.20.1
+
diff --git a/queue-5.4/hinic-fix-the-bug-of-clearing-event-queue.patch b/queue-5.4/hinic-fix-the-bug-of-clearing-event-queue.patch
new file mode 100644 (file)
index 0000000..d34955b
--- /dev/null
@@ -0,0 +1,95 @@
+From df0ca22a40ce06130b61ed19d5d46030f5810743 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 20 Mar 2020 23:13:17 +0000
+Subject: hinic: fix the bug of clearing event queue
+
+From: Luo bin <luobin9@huawei.com>
+
+[ Upstream commit 614eaa943e9fc3fcdbd4aa0692ae84973d363333 ]
+
+should disable eq irq before freeing it, must clear event queue
+depth in hw before freeing relevant memory to avoid illegal
+memory access and update consumer idx to avoid invalid interrupt
+
+Signed-off-by: Luo bin <luobin9@huawei.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ .../net/ethernet/huawei/hinic/hinic_hw_eqs.c  | 24 +++++++++++++------
+ 1 file changed, 17 insertions(+), 7 deletions(-)
+
+diff --git a/drivers/net/ethernet/huawei/hinic/hinic_hw_eqs.c b/drivers/net/ethernet/huawei/hinic/hinic_hw_eqs.c
+index 79243b626ddbe..6a723c4757bce 100644
+--- a/drivers/net/ethernet/huawei/hinic/hinic_hw_eqs.c
++++ b/drivers/net/ethernet/huawei/hinic/hinic_hw_eqs.c
+@@ -188,7 +188,7 @@ static u8 eq_cons_idx_checksum_set(u32 val)
+  * eq_update_ci - update the HW cons idx of event queue
+  * @eq: the event queue to update the cons idx for
+  **/
+-static void eq_update_ci(struct hinic_eq *eq)
++static void eq_update_ci(struct hinic_eq *eq, u32 arm_state)
+ {
+       u32 val, addr = EQ_CONS_IDX_REG_ADDR(eq);
+@@ -202,7 +202,7 @@ static void eq_update_ci(struct hinic_eq *eq)
+       val |= HINIC_EQ_CI_SET(eq->cons_idx, IDX)    |
+              HINIC_EQ_CI_SET(eq->wrapped, WRAPPED) |
+-             HINIC_EQ_CI_SET(EQ_ARMED, INT_ARMED);
++             HINIC_EQ_CI_SET(arm_state, INT_ARMED);
+       val |= HINIC_EQ_CI_SET(eq_cons_idx_checksum_set(val), XOR_CHKSUM);
+@@ -347,7 +347,7 @@ static void eq_irq_handler(void *data)
+       else if (eq->type == HINIC_CEQ)
+               ceq_irq_handler(eq);
+-      eq_update_ci(eq);
++      eq_update_ci(eq, EQ_ARMED);
+ }
+ /**
+@@ -702,7 +702,7 @@ static int init_eq(struct hinic_eq *eq, struct hinic_hwif *hwif,
+       }
+       set_eq_ctrls(eq);
+-      eq_update_ci(eq);
++      eq_update_ci(eq, EQ_ARMED);
+       err = alloc_eq_pages(eq);
+       if (err) {
+@@ -752,18 +752,28 @@ err_req_irq:
+  **/
+ static void remove_eq(struct hinic_eq *eq)
+ {
+-      struct msix_entry *entry = &eq->msix_entry;
+-
+-      free_irq(entry->vector, eq);
++      hinic_set_msix_state(eq->hwif, eq->msix_entry.entry,
++                           HINIC_MSIX_DISABLE);
++      free_irq(eq->msix_entry.vector, eq);
+       if (eq->type == HINIC_AEQ) {
+               struct hinic_eq_work *aeq_work = &eq->aeq_work;
+               cancel_work_sync(&aeq_work->work);
++              /* clear aeq_len to avoid hw access host memory */
++              hinic_hwif_write_reg(eq->hwif,
++                                   HINIC_CSR_AEQ_CTRL_1_ADDR(eq->q_id), 0);
+       } else if (eq->type == HINIC_CEQ) {
+               tasklet_kill(&eq->ceq_tasklet);
++              /* clear ceq_len to avoid hw access host memory */
++              hinic_hwif_write_reg(eq->hwif,
++                                   HINIC_CSR_CEQ_CTRL_1_ADDR(eq->q_id), 0);
+       }
++      /* update cons_idx to avoid invalid interrupt */
++      eq->cons_idx = hinic_hwif_read_reg(eq->hwif, EQ_PROD_IDX_REG_ADDR(eq));
++      eq_update_ci(eq, EQ_NOT_ARMED);
++
+       free_eq_pages(eq);
+ }
+-- 
+2.20.1
+
diff --git a/queue-5.4/hinic-fix-wrong-para-of-wait_for_completion_timeout.patch b/queue-5.4/hinic-fix-wrong-para-of-wait_for_completion_timeout.patch
new file mode 100644 (file)
index 0000000..6663f37
--- /dev/null
@@ -0,0 +1,60 @@
+From b63a6280f4fc2fa93b6236e772e73bbdbf11866b Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 20 Mar 2020 23:13:19 +0000
+Subject: hinic: fix wrong para of wait_for_completion_timeout
+
+From: Luo bin <luobin9@huawei.com>
+
+[ Upstream commit 0da7c322f116210ebfdda59c7da663a6fc5e9cc8 ]
+
+the second input parameter of wait_for_completion_timeout should
+be jiffies instead of millisecond
+
+Signed-off-by: Luo bin <luobin9@huawei.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/huawei/hinic/hinic_hw_cmdq.c | 3 ++-
+ drivers/net/ethernet/huawei/hinic/hinic_hw_mgmt.c | 5 +++--
+ 2 files changed, 5 insertions(+), 3 deletions(-)
+
+diff --git a/drivers/net/ethernet/huawei/hinic/hinic_hw_cmdq.c b/drivers/net/ethernet/huawei/hinic/hinic_hw_cmdq.c
+index 33f93cc25193a..5f2d57d1b2d37 100644
+--- a/drivers/net/ethernet/huawei/hinic/hinic_hw_cmdq.c
++++ b/drivers/net/ethernet/huawei/hinic/hinic_hw_cmdq.c
+@@ -389,7 +389,8 @@ static int cmdq_sync_cmd_direct_resp(struct hinic_cmdq *cmdq,
+       spin_unlock_bh(&cmdq->cmdq_lock);
+-      if (!wait_for_completion_timeout(&done, CMDQ_TIMEOUT)) {
++      if (!wait_for_completion_timeout(&done,
++                                       msecs_to_jiffies(CMDQ_TIMEOUT))) {
+               spin_lock_bh(&cmdq->cmdq_lock);
+               if (cmdq->errcode[curr_prod_idx] == &errcode)
+diff --git a/drivers/net/ethernet/huawei/hinic/hinic_hw_mgmt.c b/drivers/net/ethernet/huawei/hinic/hinic_hw_mgmt.c
+index c1a6be6bf6a8c..8995e32dd1c00 100644
+--- a/drivers/net/ethernet/huawei/hinic/hinic_hw_mgmt.c
++++ b/drivers/net/ethernet/huawei/hinic/hinic_hw_mgmt.c
+@@ -43,7 +43,7 @@
+ #define MSG_NOT_RESP                    0xFFFF
+-#define MGMT_MSG_TIMEOUT                1000
++#define MGMT_MSG_TIMEOUT                5000
+ #define mgmt_to_pfhwdev(pf_mgmt)        \
+               container_of(pf_mgmt, struct hinic_pfhwdev, pf_to_mgmt)
+@@ -267,7 +267,8 @@ static int msg_to_mgmt_sync(struct hinic_pf_to_mgmt *pf_to_mgmt,
+               goto unlock_sync_msg;
+       }
+-      if (!wait_for_completion_timeout(recv_done, MGMT_MSG_TIMEOUT)) {
++      if (!wait_for_completion_timeout(recv_done,
++                                       msecs_to_jiffies(MGMT_MSG_TIMEOUT))) {
+               dev_err(&pdev->dev, "MGMT timeout, MSG id = %d\n", msg_id);
+               err = -ETIMEDOUT;
+               goto unlock_sync_msg;
+-- 
+2.20.1
+
diff --git a/queue-5.4/hinic-fix-wrong-value-of-min_skb_len.patch b/queue-5.4/hinic-fix-wrong-value-of-min_skb_len.patch
new file mode 100644 (file)
index 0000000..06bdb94
--- /dev/null
@@ -0,0 +1,34 @@
+From a1e42106f82cdfc61a61209971c4436f10b87f93 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 20 Mar 2020 23:13:20 +0000
+Subject: hinic: fix wrong value of MIN_SKB_LEN
+
+From: Luo bin <luobin9@huawei.com>
+
+[ Upstream commit 7296695fc16dd1761dbba8b68a9181c71cef0633 ]
+
+the minimum value of skb len that hw supports is 32 rather than 17
+
+Signed-off-by: Luo bin <luobin9@huawei.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/huawei/hinic/hinic_tx.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/net/ethernet/huawei/hinic/hinic_tx.c b/drivers/net/ethernet/huawei/hinic/hinic_tx.c
+index 375d81d03e866..365016450bdbe 100644
+--- a/drivers/net/ethernet/huawei/hinic/hinic_tx.c
++++ b/drivers/net/ethernet/huawei/hinic/hinic_tx.c
+@@ -45,7 +45,7 @@
+ #define HW_CONS_IDX(sq)                 be16_to_cpu(*(u16 *)((sq)->hw_ci_addr))
+-#define MIN_SKB_LEN                     17
++#define MIN_SKB_LEN                   32
+ #define       MAX_PAYLOAD_OFFSET              221
+ #define TRANSPORT_OFFSET(l4_hdr, skb) ((u32)((l4_hdr) - (skb)->data))
+-- 
+2.20.1
+
diff --git a/queue-5.4/i2c-pca-platform-use-platform_irq_get_optional.patch b/queue-5.4/i2c-pca-platform-use-platform_irq_get_optional.patch
new file mode 100644 (file)
index 0000000..b2f3b17
--- /dev/null
@@ -0,0 +1,37 @@
+From 2f8128b2610107e11f307460b96b6008412c137c Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 27 Mar 2020 11:44:22 +1300
+Subject: i2c: pca-platform: Use platform_irq_get_optional
+
+From: Chris Packham <chris.packham@alliedtelesis.co.nz>
+
+[ Upstream commit 14c1fe699cad9cb0acda4559c584f136d18fea50 ]
+
+The interrupt is not required so use platform_irq_get_optional() to
+avoid error messages like
+
+  i2c-pca-platform 22080000.i2c: IRQ index 0 not found
+
+Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
+Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/i2c/busses/i2c-pca-platform.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/i2c/busses/i2c-pca-platform.c b/drivers/i2c/busses/i2c-pca-platform.c
+index a7a81846d5b1d..635dd697ac0bb 100644
+--- a/drivers/i2c/busses/i2c-pca-platform.c
++++ b/drivers/i2c/busses/i2c-pca-platform.c
+@@ -140,7 +140,7 @@ static int i2c_pca_pf_probe(struct platform_device *pdev)
+       int ret = 0;
+       int irq;
+-      irq = platform_get_irq(pdev, 0);
++      irq = platform_get_irq_optional(pdev, 0);
+       /* If irq is 0, we do polling. */
+       if (irq < 0)
+               irq = 0;
+-- 
+2.20.1
+
diff --git a/queue-5.4/i2c-st-fix-missing-struct-parameter-description.patch b/queue-5.4/i2c-st-fix-missing-struct-parameter-description.patch
new file mode 100644 (file)
index 0000000..1dfc8cd
--- /dev/null
@@ -0,0 +1,35 @@
+From 963298e0742177245daa99efaac7cee286bb0b77 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 26 Mar 2020 22:22:43 +0100
+Subject: i2c: st: fix missing struct parameter description
+
+From: Alain Volmat <avolmat@me.com>
+
+[ Upstream commit f491c6687332920e296d0209e366fe2ca7eab1c6 ]
+
+Fix a missing struct parameter description to allow
+warning free W=1 compilation.
+
+Signed-off-by: Alain Volmat <avolmat@me.com>
+Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
+Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/i2c/busses/i2c-st.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/i2c/busses/i2c-st.c b/drivers/i2c/busses/i2c-st.c
+index 54e1fc8a495e7..f7f7b5b64720e 100644
+--- a/drivers/i2c/busses/i2c-st.c
++++ b/drivers/i2c/busses/i2c-st.c
+@@ -434,6 +434,7 @@ static void st_i2c_wr_fill_tx_fifo(struct st_i2c_dev *i2c_dev)
+ /**
+  * st_i2c_rd_fill_tx_fifo() - Fill the Tx FIFO in read mode
+  * @i2c_dev: Controller's private data
++ * @max: Maximum amount of data to fill into the Tx FIFO
+  *
+  * This functions fills the Tx FIFO with fixed pattern when
+  * in read mode to trigger clock.
+-- 
+2.20.1
+
diff --git a/queue-5.4/input-tm2-touchkey-add-support-for-coreriver-tc360-v.patch b/queue-5.4/input-tm2-touchkey-add-support-for-coreriver-tc360-v.patch
new file mode 100644 (file)
index 0000000..6534ee6
--- /dev/null
@@ -0,0 +1,52 @@
+From 702bbbae8fd12227d01ebb292c1f524e9b27b549 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 15 Feb 2020 15:41:55 -0800
+Subject: Input: tm2-touchkey - add support for Coreriver TC360 variant
+
+From: Nick Reitemeyer <nick.reitemeyer@web.de>
+
+[ Upstream commit da3289044833769188c0da945d2cec90af35e87e ]
+
+The Coreriver TouchCore 360 is like the midas board touchkey, but it is
+using a fixed regulator.
+
+Signed-off-by: Nick Reitemeyer <nick.reitemeyer@web.de>
+Link: https://lore.kernel.org/r/20200121141525.3404-3-nick.reitemeyer@web.de
+Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/input/keyboard/tm2-touchkey.c | 11 +++++++++++
+ 1 file changed, 11 insertions(+)
+
+diff --git a/drivers/input/keyboard/tm2-touchkey.c b/drivers/input/keyboard/tm2-touchkey.c
+index 14b55bacdd0f1..fb078e049413f 100644
+--- a/drivers/input/keyboard/tm2-touchkey.c
++++ b/drivers/input/keyboard/tm2-touchkey.c
+@@ -75,6 +75,14 @@ static struct touchkey_variant aries_touchkey_variant = {
+       .cmd_led_off = ARIES_TOUCHKEY_CMD_LED_OFF,
+ };
++static const struct touchkey_variant tc360_touchkey_variant = {
++      .keycode_reg = 0x00,
++      .base_reg = 0x00,
++      .fixed_regulator = true,
++      .cmd_led_on = TM2_TOUCHKEY_CMD_LED_ON,
++      .cmd_led_off = TM2_TOUCHKEY_CMD_LED_OFF,
++};
++
+ static int tm2_touchkey_led_brightness_set(struct led_classdev *led_dev,
+                                           enum led_brightness brightness)
+ {
+@@ -327,6 +335,9 @@ static const struct of_device_id tm2_touchkey_of_match[] = {
+       }, {
+               .compatible = "cypress,aries-touchkey",
+               .data = &aries_touchkey_variant,
++      }, {
++              .compatible = "coreriver,tc360-touchkey",
++              .data = &tc360_touchkey_variant,
+       },
+       { },
+ };
+-- 
+2.20.1
+
diff --git a/queue-5.4/irqchip-gic-v4-provide-irq_retrigger-to-avoid-circul.patch b/queue-5.4/irqchip-gic-v4-provide-irq_retrigger-to-avoid-circul.patch
new file mode 100644 (file)
index 0000000..ea367e4
--- /dev/null
@@ -0,0 +1,146 @@
+From 831f3e72ef6794aac910dd65e94bd952415fefd2 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 10 Mar 2020 18:49:21 +0000
+Subject: irqchip/gic-v4: Provide irq_retrigger to avoid circular locking
+ dependency
+
+From: Marc Zyngier <maz@kernel.org>
+
+[ Upstream commit 7809f7011c3bce650e502a98afeb05961470d865 ]
+
+On a very heavily loaded D05 with GICv4, I managed to trigger the
+following lockdep splat:
+
+[ 6022.598864] ======================================================
+[ 6022.605031] WARNING: possible circular locking dependency detected
+[ 6022.611200] 5.6.0-rc4-00026-geee7c7b0f498 #680 Tainted: G            E
+[ 6022.618061] ------------------------------------------------------
+[ 6022.624227] qemu-system-aar/7569 is trying to acquire lock:
+[ 6022.629789] ffff042f97606808 (&p->pi_lock){-.-.}, at: try_to_wake_up+0x54/0x7a0
+[ 6022.637102]
+[ 6022.637102] but task is already holding lock:
+[ 6022.642921] ffff002fae424cf0 (&irq_desc_lock_class){-.-.}, at: __irq_get_desc_lock+0x5c/0x98
+[ 6022.651350]
+[ 6022.651350] which lock already depends on the new lock.
+[ 6022.651350]
+[ 6022.659512]
+[ 6022.659512] the existing dependency chain (in reverse order) is:
+[ 6022.666980]
+[ 6022.666980] -> #2 (&irq_desc_lock_class){-.-.}:
+[ 6022.672983]        _raw_spin_lock_irqsave+0x50/0x78
+[ 6022.677848]        __irq_get_desc_lock+0x5c/0x98
+[ 6022.682453]        irq_set_vcpu_affinity+0x40/0xc0
+[ 6022.687236]        its_make_vpe_non_resident+0x6c/0xb8
+[ 6022.692364]        vgic_v4_put+0x54/0x70
+[ 6022.696273]        vgic_v3_put+0x20/0xd8
+[ 6022.700183]        kvm_vgic_put+0x30/0x48
+[ 6022.704182]        kvm_arch_vcpu_put+0x34/0x50
+[ 6022.708614]        kvm_sched_out+0x34/0x50
+[ 6022.712700]        __schedule+0x4bc/0x7f8
+[ 6022.716697]        schedule+0x50/0xd8
+[ 6022.720347]        kvm_arch_vcpu_ioctl_run+0x5f0/0x978
+[ 6022.725473]        kvm_vcpu_ioctl+0x3d4/0x8f8
+[ 6022.729820]        ksys_ioctl+0x90/0xd0
+[ 6022.733642]        __arm64_sys_ioctl+0x24/0x30
+[ 6022.738074]        el0_svc_common.constprop.3+0xa8/0x1e8
+[ 6022.743373]        do_el0_svc+0x28/0x88
+[ 6022.747198]        el0_svc+0x14/0x40
+[ 6022.750761]        el0_sync_handler+0x124/0x2b8
+[ 6022.755278]        el0_sync+0x140/0x180
+[ 6022.759100]
+[ 6022.759100] -> #1 (&rq->lock){-.-.}:
+[ 6022.764143]        _raw_spin_lock+0x38/0x50
+[ 6022.768314]        task_fork_fair+0x40/0x128
+[ 6022.772572]        sched_fork+0xe0/0x210
+[ 6022.776484]        copy_process+0x8c4/0x18d8
+[ 6022.780742]        _do_fork+0x88/0x6d8
+[ 6022.784478]        kernel_thread+0x64/0x88
+[ 6022.788563]        rest_init+0x30/0x270
+[ 6022.792390]        arch_call_rest_init+0x14/0x1c
+[ 6022.796995]        start_kernel+0x498/0x4c4
+[ 6022.801164]
+[ 6022.801164] -> #0 (&p->pi_lock){-.-.}:
+[ 6022.806382]        __lock_acquire+0xdd8/0x15c8
+[ 6022.810813]        lock_acquire+0xd0/0x218
+[ 6022.814896]        _raw_spin_lock_irqsave+0x50/0x78
+[ 6022.819761]        try_to_wake_up+0x54/0x7a0
+[ 6022.824018]        wake_up_process+0x1c/0x28
+[ 6022.828276]        wakeup_softirqd+0x38/0x40
+[ 6022.832533]        __tasklet_schedule_common+0xc4/0xf0
+[ 6022.837658]        __tasklet_schedule+0x24/0x30
+[ 6022.842176]        check_irq_resend+0xc8/0x158
+[ 6022.846609]        irq_startup+0x74/0x128
+[ 6022.850606]        __enable_irq+0x6c/0x78
+[ 6022.854602]        enable_irq+0x54/0xa0
+[ 6022.858431]        its_make_vpe_non_resident+0xa4/0xb8
+[ 6022.863557]        vgic_v4_put+0x54/0x70
+[ 6022.867469]        kvm_arch_vcpu_blocking+0x28/0x38
+[ 6022.872336]        kvm_vcpu_block+0x48/0x490
+[ 6022.876594]        kvm_handle_wfx+0x18c/0x310
+[ 6022.880938]        handle_exit+0x138/0x198
+[ 6022.885022]        kvm_arch_vcpu_ioctl_run+0x4d4/0x978
+[ 6022.890148]        kvm_vcpu_ioctl+0x3d4/0x8f8
+[ 6022.894494]        ksys_ioctl+0x90/0xd0
+[ 6022.898317]        __arm64_sys_ioctl+0x24/0x30
+[ 6022.902748]        el0_svc_common.constprop.3+0xa8/0x1e8
+[ 6022.908046]        do_el0_svc+0x28/0x88
+[ 6022.911871]        el0_svc+0x14/0x40
+[ 6022.915434]        el0_sync_handler+0x124/0x2b8
+[ 6022.919951]        el0_sync+0x140/0x180
+[ 6022.923773]
+[ 6022.923773] other info that might help us debug this:
+[ 6022.923773]
+[ 6022.931762] Chain exists of:
+[ 6022.931762]   &p->pi_lock --> &rq->lock --> &irq_desc_lock_class
+[ 6022.931762]
+[ 6022.942101]  Possible unsafe locking scenario:
+[ 6022.942101]
+[ 6022.948007]        CPU0                    CPU1
+[ 6022.952523]        ----                    ----
+[ 6022.957039]   lock(&irq_desc_lock_class);
+[ 6022.961036]                                lock(&rq->lock);
+[ 6022.966595]                                lock(&irq_desc_lock_class);
+[ 6022.973109]   lock(&p->pi_lock);
+[ 6022.976324]
+[ 6022.976324]  *** DEADLOCK ***
+
+This is happening because we have a pending doorbell that requires
+retrigger. As SW retriggering is done in a tasklet, we trigger the
+circular dependency above.
+
+The easy cop-out is to provide a retrigger callback that doesn't
+require acquiring any extra lock.
+
+Signed-off-by: Marc Zyngier <maz@kernel.org>
+Link: https://lore.kernel.org/r/20200310184921.23552-5-maz@kernel.org
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/irqchip/irq-gic-v3-its.c | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
+index 11f3b50dcdcb8..263cf9240b168 100644
+--- a/drivers/irqchip/irq-gic-v3-its.c
++++ b/drivers/irqchip/irq-gic-v3-its.c
+@@ -2985,12 +2985,18 @@ static int its_vpe_set_irqchip_state(struct irq_data *d,
+       return 0;
+ }
++static int its_vpe_retrigger(struct irq_data *d)
++{
++      return !its_vpe_set_irqchip_state(d, IRQCHIP_STATE_PENDING, true);
++}
++
+ static struct irq_chip its_vpe_irq_chip = {
+       .name                   = "GICv4-vpe",
+       .irq_mask               = its_vpe_mask_irq,
+       .irq_unmask             = its_vpe_unmask_irq,
+       .irq_eoi                = irq_chip_eoi_parent,
+       .irq_set_affinity       = its_vpe_set_affinity,
++      .irq_retrigger          = its_vpe_retrigger,
+       .irq_set_irqchip_state  = its_vpe_set_irqchip_state,
+       .irq_set_vcpu_affinity  = its_vpe_set_vcpu_affinity,
+ };
+-- 
+2.20.1
+
diff --git a/queue-5.4/irqchip-versatile-fpga-handle-chained-irqs-properly.patch b/queue-5.4/irqchip-versatile-fpga-handle-chained-irqs-properly.patch
new file mode 100644 (file)
index 0000000..0d14468
--- /dev/null
@@ -0,0 +1,69 @@
+From 9422f36ca6fb795f59a49ab6b3522ed003e8b5f0 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 19 Mar 2020 11:34:48 +0900
+Subject: irqchip/versatile-fpga: Handle chained IRQs properly
+
+From: Sungbo Eo <mans0n@gorani.run>
+
+[ Upstream commit 486562da598c59e9f835b551d7cf19507de2d681 ]
+
+Enclose the chained handler with chained_irq_{enter,exit}(), so that the
+muxed interrupts get properly acked.
+
+This patch also fixes a reboot bug on OX820 SoC, where the jiffies timer
+interrupt is never acked. The kernel waits a clock tick forever in
+calibrate_delay_converge(), which leads to a boot hang.
+
+Fixes: c41b16f8c9d9 ("ARM: integrator/versatile: consolidate FPGA IRQ handling code")
+Signed-off-by: Sungbo Eo <mans0n@gorani.run>
+Signed-off-by: Marc Zyngier <maz@kernel.org>
+Link: https://lore.kernel.org/r/20200319023448.1479701-1-mans0n@gorani.run
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/irqchip/irq-versatile-fpga.c | 12 ++++++++++--
+ 1 file changed, 10 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/irqchip/irq-versatile-fpga.c b/drivers/irqchip/irq-versatile-fpga.c
+index 928858dada756..70e2cfff8175f 100644
+--- a/drivers/irqchip/irq-versatile-fpga.c
++++ b/drivers/irqchip/irq-versatile-fpga.c
+@@ -6,6 +6,7 @@
+ #include <linux/irq.h>
+ #include <linux/io.h>
+ #include <linux/irqchip.h>
++#include <linux/irqchip/chained_irq.h>
+ #include <linux/irqchip/versatile-fpga.h>
+ #include <linux/irqdomain.h>
+ #include <linux/module.h>
+@@ -68,12 +69,16 @@ static void fpga_irq_unmask(struct irq_data *d)
+ static void fpga_irq_handle(struct irq_desc *desc)
+ {
++      struct irq_chip *chip = irq_desc_get_chip(desc);
+       struct fpga_irq_data *f = irq_desc_get_handler_data(desc);
+-      u32 status = readl(f->base + IRQ_STATUS);
++      u32 status;
++
++      chained_irq_enter(chip, desc);
++      status = readl(f->base + IRQ_STATUS);
+       if (status == 0) {
+               do_bad_IRQ(desc);
+-              return;
++              goto out;
+       }
+       do {
+@@ -82,6 +87,9 @@ static void fpga_irq_handle(struct irq_desc *desc)
+               status &= ~(1 << irq);
+               generic_handle_irq(irq_find_mapping(f->domain, irq));
+       } while (status);
++
++out:
++      chained_irq_exit(chip, desc);
+ }
+ /*
+-- 
+2.20.1
+
diff --git a/queue-5.4/iwlwifi-mvm-fix-rate-scale-nss-configuration.patch b/queue-5.4/iwlwifi-mvm-fix-rate-scale-nss-configuration.patch
new file mode 100644 (file)
index 0000000..3246695
--- /dev/null
@@ -0,0 +1,95 @@
+From be294657edf8830fd2e7923a081897344e913079 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 6 Mar 2020 15:16:26 +0200
+Subject: iwlwifi: mvm: Fix rate scale NSS configuration
+
+From: Ilan Peer <ilan.peer@intel.com>
+
+[ Upstream commit ce19801ba75a902ab515dda03b57738c708d0781 ]
+
+The TLC configuration did not take into consideration the station's
+SMPS configuration, and thus configured rates for 2 NSS even if
+static SMPS was reported by the station. Fix this.
+
+Signed-off-by: Ilan Peer <ilan.peer@intel.com>
+Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
+Link: https://lore.kernel.org/r/iwlwifi.20200306151129.b4f940d13eca.Ieebfa889d08205a3a961ae0138fb5832e8a0f9c1@changeid
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ .../net/wireless/intel/iwlwifi/mvm/rs-fw.c    | 29 ++++++++++++++-----
+ 1 file changed, 21 insertions(+), 8 deletions(-)
+
+diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/rs-fw.c b/drivers/net/wireless/intel/iwlwifi/mvm/rs-fw.c
+index 24df3182ec9eb..5b2bd603febfc 100644
+--- a/drivers/net/wireless/intel/iwlwifi/mvm/rs-fw.c
++++ b/drivers/net/wireless/intel/iwlwifi/mvm/rs-fw.c
+@@ -6,7 +6,7 @@
+  * GPL LICENSE SUMMARY
+  *
+  * Copyright(c) 2017        Intel Deutschland GmbH
+- * Copyright(c) 2018 - 2019 Intel Corporation
++ * Copyright(c) 2018 - 2020 Intel Corporation
+  *
+  * This program is free software; you can redistribute it and/or modify
+  * it under the terms of version 2 of the GNU General Public License as
+@@ -27,7 +27,7 @@
+  * BSD LICENSE
+  *
+  * Copyright(c) 2017        Intel Deutschland GmbH
+- * Copyright(c) 2018 - 2019 Intel Corporation
++ * Copyright(c) 2018 - 2020 Intel Corporation
+  * All rights reserved.
+  *
+  * Redistribution and use in source and binary forms, with or without
+@@ -195,11 +195,13 @@ rs_fw_vht_set_enabled_rates(const struct ieee80211_sta *sta,
+ {
+       u16 supp;
+       int i, highest_mcs;
++      u8 nss = sta->rx_nss;
+-      for (i = 0; i < sta->rx_nss; i++) {
+-              if (i == IWL_TLC_NSS_MAX)
+-                      break;
++      /* the station support only a single receive chain */
++      if (sta->smps_mode == IEEE80211_SMPS_STATIC)
++              nss = 1;
++      for (i = 0; i < nss && i < IWL_TLC_NSS_MAX; i++) {
+               highest_mcs = rs_fw_vht_highest_rx_mcs_index(vht_cap, i + 1);
+               if (!highest_mcs)
+                       continue;
+@@ -245,8 +247,13 @@ rs_fw_he_set_enabled_rates(const struct ieee80211_sta *sta,
+       u16 tx_mcs_160 =
+               le16_to_cpu(sband->iftype_data->he_cap.he_mcs_nss_supp.tx_mcs_160);
+       int i;
++      u8 nss = sta->rx_nss;
+-      for (i = 0; i < sta->rx_nss && i < IWL_TLC_NSS_MAX; i++) {
++      /* the station support only a single receive chain */
++      if (sta->smps_mode == IEEE80211_SMPS_STATIC)
++              nss = 1;
++
++      for (i = 0; i < nss && i < IWL_TLC_NSS_MAX; i++) {
+               u16 _mcs_160 = (mcs_160 >> (2 * i)) & 0x3;
+               u16 _mcs_80 = (mcs_80 >> (2 * i)) & 0x3;
+               u16 _tx_mcs_160 = (tx_mcs_160 >> (2 * i)) & 0x3;
+@@ -307,8 +314,14 @@ static void rs_fw_set_supp_rates(struct ieee80211_sta *sta,
+               cmd->mode = IWL_TLC_MNG_MODE_HT;
+               cmd->ht_rates[IWL_TLC_NSS_1][IWL_TLC_HT_BW_NONE_160] =
+                       cpu_to_le16(ht_cap->mcs.rx_mask[0]);
+-              cmd->ht_rates[IWL_TLC_NSS_2][IWL_TLC_HT_BW_NONE_160] =
+-                      cpu_to_le16(ht_cap->mcs.rx_mask[1]);
++
++              /* the station support only a single receive chain */
++              if (sta->smps_mode == IEEE80211_SMPS_STATIC)
++                      cmd->ht_rates[IWL_TLC_NSS_2][IWL_TLC_HT_BW_NONE_160] =
++                              0;
++              else
++                      cmd->ht_rates[IWL_TLC_NSS_2][IWL_TLC_HT_BW_NONE_160] =
++                              cpu_to_le16(ht_cap->mcs.rx_mask[1]);
+       }
+ }
+-- 
+2.20.1
+
diff --git a/queue-5.4/libata-remove-extra-scsi_host_put-in-ata_scsi_add_ho.patch b/queue-5.4/libata-remove-extra-scsi_host_put-in-ata_scsi_add_ho.patch
new file mode 100644 (file)
index 0000000..893e82b
--- /dev/null
@@ -0,0 +1,158 @@
+From 6176ad1982b8cee2f91b0de1f2e049b0bca7a7b0 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 28 Feb 2020 19:33:35 +0800
+Subject: libata: Remove extra scsi_host_put() in ata_scsi_add_hosts()
+
+From: John Garry <john.garry@huawei.com>
+
+[ Upstream commit 1d72f7aec3595249dbb83291ccac041a2d676c57 ]
+
+If the call to scsi_add_host_with_dma() in ata_scsi_add_hosts() fails,
+then we may get use-after-free KASAN warns:
+
+==================================================================
+BUG: KASAN: use-after-free in kobject_put+0x24/0x180
+Read of size 1 at addr ffff0026b8c80364 by task swapper/0/1
+CPU: 1 PID: 1 Comm: swapper/0 Tainted: G        W         5.6.0-rc3-00004-g5a71b206ea82-dirty #1765
+Hardware name: Huawei TaiShan 200 (Model 2280)/BC82AMDD, BIOS 2280-V2 CS V3.B160.01 02/24/2020
+Call trace:
+dump_backtrace+0x0/0x298
+show_stack+0x14/0x20
+dump_stack+0x118/0x190
+print_address_description.isra.9+0x6c/0x3b8
+__kasan_report+0x134/0x23c
+kasan_report+0xc/0x18
+__asan_load1+0x5c/0x68
+kobject_put+0x24/0x180
+put_device+0x10/0x20
+scsi_host_put+0x10/0x18
+ata_devres_release+0x74/0xb0
+release_nodes+0x2d0/0x470
+devres_release_all+0x50/0x78
+really_probe+0x2d4/0x560
+driver_probe_device+0x7c/0x148
+device_driver_attach+0x94/0xa0
+__driver_attach+0xa8/0x110
+bus_for_each_dev+0xe8/0x158
+driver_attach+0x30/0x40
+bus_add_driver+0x220/0x2e0
+driver_register+0xbc/0x1d0
+__pci_register_driver+0xbc/0xd0
+ahci_pci_driver_init+0x20/0x28
+do_one_initcall+0xf0/0x608
+kernel_init_freeable+0x31c/0x384
+kernel_init+0x10/0x118
+ret_from_fork+0x10/0x18
+
+Allocated by task 5:
+save_stack+0x28/0xc8
+__kasan_kmalloc.isra.8+0xbc/0xd8
+kasan_kmalloc+0xc/0x18
+__kmalloc+0x1a8/0x280
+scsi_host_alloc+0x44/0x678
+ata_scsi_add_hosts+0x74/0x268
+ata_host_register+0x228/0x488
+ahci_host_activate+0x1c4/0x2a8
+ahci_init_one+0xd18/0x1298
+local_pci_probe+0x74/0xf0
+work_for_cpu_fn+0x2c/0x48
+process_one_work+0x488/0xc08
+worker_thread+0x330/0x5d0
+kthread+0x1c8/0x1d0
+ret_from_fork+0x10/0x18
+
+Freed by task 5:
+save_stack+0x28/0xc8
+__kasan_slab_free+0x118/0x180
+kasan_slab_free+0x10/0x18
+slab_free_freelist_hook+0xa4/0x1a0
+kfree+0xd4/0x3a0
+scsi_host_dev_release+0x100/0x148
+device_release+0x7c/0xe0
+kobject_put+0xb0/0x180
+put_device+0x10/0x20
+scsi_host_put+0x10/0x18
+ata_scsi_add_hosts+0x210/0x268
+ata_host_register+0x228/0x488
+ahci_host_activate+0x1c4/0x2a8
+ahci_init_one+0xd18/0x1298
+local_pci_probe+0x74/0xf0
+work_for_cpu_fn+0x2c/0x48
+process_one_work+0x488/0xc08
+worker_thread+0x330/0x5d0
+kthread+0x1c8/0x1d0
+ret_from_fork+0x10/0x18
+
+There is also refcount issue, as well:
+WARNING: CPU: 1 PID: 1 at lib/refcount.c:28 refcount_warn_saturate+0xf8/0x170
+
+The issue is that we make an erroneous extra call to scsi_host_put()
+for that host:
+
+So in ahci_init_one()->ata_host_alloc_pinfo()->ata_host_alloc(), we setup
+a device release method - ata_devres_release() - which intends to release
+the SCSI hosts:
+
+static void ata_devres_release(struct device *gendev, void *res)
+{
+       ...
+       for (i = 0; i < host->n_ports; i++) {
+               struct ata_port *ap = host->ports[i];
+
+               if (!ap)
+                       continue;
+
+               if (ap->scsi_host)
+                       scsi_host_put(ap->scsi_host);
+
+       }
+       ...
+}
+
+However in the ata_scsi_add_hosts() error path, we also call
+scsi_host_put() for the SCSI hosts.
+
+Fix by removing the the scsi_host_put() calls in ata_scsi_add_hosts() and
+leave this to ata_devres_release().
+
+Fixes: f31871951b38 ("libata: separate out ata_host_alloc() and ata_host_register()")
+Signed-off-by: John Garry <john.garry@huawei.com>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/ata/libata-scsi.c | 9 +++------
+ 1 file changed, 3 insertions(+), 6 deletions(-)
+
+diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
+index 58e09ffe8b9cb..5af34a3201ed2 100644
+--- a/drivers/ata/libata-scsi.c
++++ b/drivers/ata/libata-scsi.c
+@@ -4553,22 +4553,19 @@ int ata_scsi_add_hosts(struct ata_host *host, struct scsi_host_template *sht)
+                */
+               shost->max_host_blocked = 1;
+-              rc = scsi_add_host_with_dma(ap->scsi_host,
+-                                              &ap->tdev, ap->host->dev);
++              rc = scsi_add_host_with_dma(shost, &ap->tdev, ap->host->dev);
+               if (rc)
+-                      goto err_add;
++                      goto err_alloc;
+       }
+       return 0;
+- err_add:
+-      scsi_host_put(host->ports[i]->scsi_host);
+  err_alloc:
+       while (--i >= 0) {
+               struct Scsi_Host *shost = host->ports[i]->scsi_host;
++              /* scsi_host_put() is in ata_devres_release() */
+               scsi_remove_host(shost);
+-              scsi_host_put(shost);
+       }
+       return rc;
+ }
+-- 
+2.20.1
+
diff --git a/queue-5.4/locking-lockdep-avoid-recursion-in-lockdep_count_-fo.patch b/queue-5.4/locking-lockdep-avoid-recursion-in-lockdep_count_-fo.patch
new file mode 100644 (file)
index 0000000..1284fcf
--- /dev/null
@@ -0,0 +1,80 @@
+From 1e63bcf56e36425e9f5619125627af25514df7eb Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 12 Mar 2020 23:12:55 +0800
+Subject: locking/lockdep: Avoid recursion in
+ lockdep_count_{for,back}ward_deps()
+
+From: Boqun Feng <boqun.feng@gmail.com>
+
+[ Upstream commit 25016bd7f4caf5fc983bbab7403d08e64cba3004 ]
+
+Qian Cai reported a bug when PROVE_RCU_LIST=y, and read on /proc/lockdep
+triggered a warning:
+
+  [ ] DEBUG_LOCKS_WARN_ON(current->hardirqs_enabled)
+  ...
+  [ ] Call Trace:
+  [ ]  lock_is_held_type+0x5d/0x150
+  [ ]  ? rcu_lockdep_current_cpu_online+0x64/0x80
+  [ ]  rcu_read_lock_any_held+0xac/0x100
+  [ ]  ? rcu_read_lock_held+0xc0/0xc0
+  [ ]  ? __slab_free+0x421/0x540
+  [ ]  ? kasan_kmalloc+0x9/0x10
+  [ ]  ? __kmalloc_node+0x1d7/0x320
+  [ ]  ? kvmalloc_node+0x6f/0x80
+  [ ]  __bfs+0x28a/0x3c0
+  [ ]  ? class_equal+0x30/0x30
+  [ ]  lockdep_count_forward_deps+0x11a/0x1a0
+
+The warning got triggered because lockdep_count_forward_deps() call
+__bfs() without current->lockdep_recursion being set, as a result
+a lockdep internal function (__bfs()) is checked by lockdep, which is
+unexpected, and the inconsistency between the irq-off state and the
+state traced by lockdep caused the warning.
+
+Apart from this warning, lockdep internal functions like __bfs() should
+always be protected by current->lockdep_recursion to avoid potential
+deadlocks and data inconsistency, therefore add the
+current->lockdep_recursion on-and-off section to protect __bfs() in both
+lockdep_count_forward_deps() and lockdep_count_backward_deps()
+
+Reported-by: Qian Cai <cai@lca.pw>
+Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
+Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Link: https://lkml.kernel.org/r/20200312151258.128036-1-boqun.feng@gmail.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ kernel/locking/lockdep.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
+index 35d3b6925b1ee..9ab1a965c3b92 100644
+--- a/kernel/locking/lockdep.c
++++ b/kernel/locking/lockdep.c
+@@ -1719,9 +1719,11 @@ unsigned long lockdep_count_forward_deps(struct lock_class *class)
+       this.class = class;
+       raw_local_irq_save(flags);
++      current->lockdep_recursion = 1;
+       arch_spin_lock(&lockdep_lock);
+       ret = __lockdep_count_forward_deps(&this);
+       arch_spin_unlock(&lockdep_lock);
++      current->lockdep_recursion = 0;
+       raw_local_irq_restore(flags);
+       return ret;
+@@ -1746,9 +1748,11 @@ unsigned long lockdep_count_backward_deps(struct lock_class *class)
+       this.class = class;
+       raw_local_irq_save(flags);
++      current->lockdep_recursion = 1;
+       arch_spin_lock(&lockdep_lock);
+       ret = __lockdep_count_backward_deps(&this);
+       arch_spin_unlock(&lockdep_lock);
++      current->lockdep_recursion = 0;
+       raw_local_irq_restore(flags);
+       return ret;
+-- 
+2.20.1
+
diff --git a/queue-5.4/md-check-arrays-is-suspended-in-mddev_detach-before-.patch b/queue-5.4/md-check-arrays-is-suspended-in-mddev_detach-before-.patch
new file mode 100644 (file)
index 0000000..1ae93d6
--- /dev/null
@@ -0,0 +1,66 @@
+From ae700b96e1659682ff63ade4cb15e71451290dbb Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 11 Feb 2020 11:10:04 +0100
+Subject: md: check arrays is suspended in mddev_detach before call quiesce
+ operations
+
+From: Guoqing Jiang <guoqing.jiang@cloud.ionos.com>
+
+[ Upstream commit 6b40bec3b13278d21fa6c1ae7a0bdf2e550eed5f ]
+
+Don't call quiesce(1) and quiesce(0) if array is already suspended,
+otherwise in level_store, the array is writable after mddev_detach
+in below part though the intention is to make array writable after
+resume.
+
+       mddev_suspend(mddev);
+       mddev_detach(mddev);
+       ...
+       mddev_resume(mddev);
+
+And it also causes calltrace as follows in [1].
+
+[48005.653834] WARNING: CPU: 1 PID: 45380 at kernel/kthread.c:510 kthread_park+0x77/0x90
+[...]
+[48005.653976] CPU: 1 PID: 45380 Comm: mdadm Tainted: G           OE     5.4.10-arch1-1 #1
+[48005.653979] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./J4105-ITX, BIOS P1.40 08/06/2018
+[48005.653984] RIP: 0010:kthread_park+0x77/0x90
+[48005.654015] Call Trace:
+[48005.654039]  r5l_quiesce+0x3c/0x70 [raid456]
+[48005.654052]  raid5_quiesce+0x228/0x2e0 [raid456]
+[48005.654073]  mddev_detach+0x30/0x70 [md_mod]
+[48005.654090]  level_store+0x202/0x670 [md_mod]
+[48005.654099]  ? security_capable+0x40/0x60
+[48005.654114]  md_attr_store+0x7b/0xc0 [md_mod]
+[48005.654123]  kernfs_fop_write+0xce/0x1b0
+[48005.654132]  vfs_write+0xb6/0x1a0
+[48005.654138]  ksys_write+0x67/0xe0
+[48005.654146]  do_syscall_64+0x4e/0x140
+[48005.654155]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
+[48005.654161] RIP: 0033:0x7fa0c8737497
+
+[1]: https://bugzilla.kernel.org/show_bug.cgi?id=206161
+
+Signed-off-by: Guoqing Jiang <guoqing.jiang@cloud.ionos.com>
+Signed-off-by: Song Liu <songliubraving@fb.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/md/md.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/md/md.c b/drivers/md/md.c
+index 4e7c9f398bc66..6b69a12ca2d80 100644
+--- a/drivers/md/md.c
++++ b/drivers/md/md.c
+@@ -6040,7 +6040,7 @@ EXPORT_SYMBOL_GPL(md_stop_writes);
+ static void mddev_detach(struct mddev *mddev)
+ {
+       md_bitmap_wait_behind_writes(mddev);
+-      if (mddev->pers && mddev->pers->quiesce) {
++      if (mddev->pers && mddev->pers->quiesce && !mddev->suspended) {
+               mddev->pers->quiesce(mddev, 1);
+               mddev->pers->quiesce(mddev, 0);
+       }
+-- 
+2.20.1
+
diff --git a/queue-5.4/media-allegro-fix-type-of-gop_length-in-channel_crea.patch b/queue-5.4/media-allegro-fix-type-of-gop_length-in-channel_crea.patch
new file mode 100644 (file)
index 0000000..4af4cd4
--- /dev/null
@@ -0,0 +1,44 @@
+From 28533e24c6015556fa955fd91c72bd09a12f21eb Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 16 Mar 2020 16:26:23 +0100
+Subject: media: allegro: fix type of gop_length in channel_create message
+
+From: Michael Tretter <m.tretter@pengutronix.de>
+
+[ Upstream commit 8277815349327b8e65226eb58ddb680f90c2c0c0 ]
+
+The gop_length field is actually only u16 and there are two more u8
+fields in the message:
+
+- the number of consecutive b-frames
+- frequency of golden frames
+
+Fix the message and thus fix the configuration of the GOP length.
+
+Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/staging/media/allegro-dvt/allegro-core.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/staging/media/allegro-dvt/allegro-core.c b/drivers/staging/media/allegro-dvt/allegro-core.c
+index 6f0cd07847863..c5a262a12e401 100644
+--- a/drivers/staging/media/allegro-dvt/allegro-core.c
++++ b/drivers/staging/media/allegro-dvt/allegro-core.c
+@@ -393,7 +393,10 @@ struct mcu_msg_create_channel {
+       u32 freq_ird;
+       u32 freq_lt;
+       u32 gdr_mode;
+-      u32 gop_length;
++      u16 gop_length;
++      u8 num_b;
++      u8 freq_golden_ref;
++
+       u32 unknown39;
+       u32 subframe_latency;
+-- 
+2.20.1
+
diff --git a/queue-5.4/media-i2c-ov5695-fix-power-on-and-off-sequences.patch b/queue-5.4/media-i2c-ov5695-fix-power-on-and-off-sequences.patch
new file mode 100644 (file)
index 0000000..8926d1d
--- /dev/null
@@ -0,0 +1,134 @@
+From 13e930f20399d3988eae36782d64711f00c295f4 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 11 Mar 2020 11:47:28 +0100
+Subject: media: i2c: ov5695: Fix power on and off sequences
+
+From: Dongchun Zhu <dongchun.zhu@mediatek.com>
+
+[ Upstream commit f1a64f56663e9d03e509439016dcbddd0166b2da ]
+
+From the measured hardware signal, OV5695 reset pin goes high for a
+short period of time during boot-up. From the sensor specification, the
+reset pin is active low and the DT binding defines the pin as active
+low, which means that the values set by the driver are inverted and thus
+the value requested in probe ends up high.
+
+Fix it by changing probe to request the reset GPIO initialized to high,
+which makes the initial state of the physical signal low.
+
+In addition, DOVDD rising must occur before DVDD rising from spec., but
+regulator_bulk_enable() API enables all the regulators asynchronously.
+Use an explicit loops of regulator_enable() instead.
+
+For power off sequence, it is required that DVDD falls first. Given the
+bulk API does not give any guarantee about the order of regulators,
+change the driver to use regulator_disable() instead.
+
+The sensor also requires a delay between reset high and first I2C
+transaction, which was assumed to be 8192 XVCLK cycles, but 1ms is
+recommended by the vendor. Fix this as well.
+
+Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
+Signed-off-by: Tomasz Figa <tfiga@chromium.org>
+Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/media/i2c/ov5695.c | 49 ++++++++++++++++++++++++--------------
+ 1 file changed, 31 insertions(+), 18 deletions(-)
+
+diff --git a/drivers/media/i2c/ov5695.c b/drivers/media/i2c/ov5695.c
+index 34b7046d97021..1adcd1ed16641 100644
+--- a/drivers/media/i2c/ov5695.c
++++ b/drivers/media/i2c/ov5695.c
+@@ -971,16 +971,9 @@ unlock_and_return:
+       return ret;
+ }
+-/* Calculate the delay in us by clock rate and clock cycles */
+-static inline u32 ov5695_cal_delay(u32 cycles)
+-{
+-      return DIV_ROUND_UP(cycles, OV5695_XVCLK_FREQ / 1000 / 1000);
+-}
+-
+ static int __ov5695_power_on(struct ov5695 *ov5695)
+ {
+-      int ret;
+-      u32 delay_us;
++      int i, ret;
+       struct device *dev = &ov5695->client->dev;
+       ret = clk_prepare_enable(ov5695->xvclk);
+@@ -991,21 +984,28 @@ static int __ov5695_power_on(struct ov5695 *ov5695)
+       gpiod_set_value_cansleep(ov5695->reset_gpio, 1);
+-      ret = regulator_bulk_enable(OV5695_NUM_SUPPLIES, ov5695->supplies);
+-      if (ret < 0) {
+-              dev_err(dev, "Failed to enable regulators\n");
+-              goto disable_clk;
++      /*
++       * The hardware requires the regulators to be powered on in order,
++       * so enable them one by one.
++       */
++      for (i = 0; i < OV5695_NUM_SUPPLIES; i++) {
++              ret = regulator_enable(ov5695->supplies[i].consumer);
++              if (ret) {
++                      dev_err(dev, "Failed to enable %s: %d\n",
++                              ov5695->supplies[i].supply, ret);
++                      goto disable_reg_clk;
++              }
+       }
+       gpiod_set_value_cansleep(ov5695->reset_gpio, 0);
+-      /* 8192 cycles prior to first SCCB transaction */
+-      delay_us = ov5695_cal_delay(8192);
+-      usleep_range(delay_us, delay_us * 2);
++      usleep_range(1000, 1200);
+       return 0;
+-disable_clk:
++disable_reg_clk:
++      for (--i; i >= 0; i--)
++              regulator_disable(ov5695->supplies[i].consumer);
+       clk_disable_unprepare(ov5695->xvclk);
+       return ret;
+@@ -1013,9 +1013,22 @@ disable_clk:
+ static void __ov5695_power_off(struct ov5695 *ov5695)
+ {
++      struct device *dev = &ov5695->client->dev;
++      int i, ret;
++
+       clk_disable_unprepare(ov5695->xvclk);
+       gpiod_set_value_cansleep(ov5695->reset_gpio, 1);
+-      regulator_bulk_disable(OV5695_NUM_SUPPLIES, ov5695->supplies);
++
++      /*
++       * The hardware requires the regulators to be powered off in order,
++       * so disable them one by one.
++       */
++      for (i = OV5695_NUM_SUPPLIES - 1; i >= 0; i--) {
++              ret = regulator_disable(ov5695->supplies[i].consumer);
++              if (ret)
++                      dev_err(dev, "Failed to disable %s: %d\n",
++                              ov5695->supplies[i].supply, ret);
++      }
+ }
+ static int __maybe_unused ov5695_runtime_resume(struct device *dev)
+@@ -1285,7 +1298,7 @@ static int ov5695_probe(struct i2c_client *client,
+       if (clk_get_rate(ov5695->xvclk) != OV5695_XVCLK_FREQ)
+               dev_warn(dev, "xvclk mismatched, modes are based on 24MHz\n");
+-      ov5695->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
++      ov5695->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
+       if (IS_ERR(ov5695->reset_gpio)) {
+               dev_err(dev, "Failed to get reset-gpios\n");
+               return -EINVAL;
+-- 
+2.20.1
+
diff --git a/queue-5.4/media-i2c-video-i2c-fix-build-errors-due-to-imply-hw.patch b/queue-5.4/media-i2c-video-i2c-fix-build-errors-due-to-imply-hw.patch
new file mode 100644 (file)
index 0000000..8d8b5e6
--- /dev/null
@@ -0,0 +1,43 @@
+From d64cce7f6afb77d814789b1a4ea00d67e6813d82 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 24 Mar 2020 02:07:41 +0100
+Subject: media: i2c: video-i2c: fix build errors due to 'imply hwmon'
+
+From: Matt Ranostay <matt.ranostay@konsulko.com>
+
+[ Upstream commit 64d4fc9926f09861a35d8f0f7d81f056e6d5af7b ]
+
+Fix build fault when CONFIG_HWMON is a module, and CONFIG_VIDEO_I2C
+as builtin. This is due to 'imply hwmon' in the respective Kconfig.
+
+Issue build log:
+
+ld: drivers/media/i2c/video-i2c.o: in function `amg88xx_hwmon_init':
+video-i2c.c:(.text+0x2e1): undefined reference to `devm_hwmon_device_register_with_info
+
+Cc: rdunlap@infradead.org
+Fixes: acbea6798955 (media: video-i2c: add hwmon support for amg88xx)
+Signed-off-by: Matt Ranostay <matt.ranostay@konsulko.com>
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/media/i2c/video-i2c.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/media/i2c/video-i2c.c b/drivers/media/i2c/video-i2c.c
+index 078141712c887..0b977e73ceb29 100644
+--- a/drivers/media/i2c/video-i2c.c
++++ b/drivers/media/i2c/video-i2c.c
+@@ -255,7 +255,7 @@ static int amg88xx_set_power(struct video_i2c_data *data, bool on)
+       return amg88xx_set_power_off(data);
+ }
+-#if IS_ENABLED(CONFIG_HWMON)
++#if IS_REACHABLE(CONFIG_HWMON)
+ static const u32 amg88xx_temp_config[] = {
+       HWMON_T_INPUT,
+-- 
+2.20.1
+
diff --git a/queue-5.4/media-imx-imx7-media-csi-fix-video-field-handling.patch b/queue-5.4/media-imx-imx7-media-csi-fix-video-field-handling.patch
new file mode 100644 (file)
index 0000000..14553be
--- /dev/null
@@ -0,0 +1,51 @@
+From 4c68a8820e18696111a9efbd7060b21cef9929cb Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 10 Mar 2020 17:06:29 +0100
+Subject: media: imx: imx7-media-csi: Fix video field handling
+
+From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+
+[ Upstream commit f7b8488bd39ae8feced4dfbb41cf1431277b893f ]
+
+Commit 4791bd7d6adc ("media: imx: Try colorimetry at both sink and
+source pads") reworked the way that formats are set on the sink pad of
+the CSI subdevice, and accidentally removed video field handling.
+Restore it by defaulting to V4L2_FIELD_NONE if the field value isn't
+supported, with the only two supported value being V4L2_FIELD_NONE and
+V4L2_FIELD_INTERLACED.
+
+Fixes: 4791bd7d6adc ("media: imx: Try colorimetry at both sink and source pads")
+Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+Reviewed-by: Rui Miguel Silva <rmfrfs@gmail.com>
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/staging/media/imx/imx7-media-csi.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+diff --git a/drivers/staging/media/imx/imx7-media-csi.c b/drivers/staging/media/imx/imx7-media-csi.c
+index bfd6b5fbf4841..d24897d06947f 100644
+--- a/drivers/staging/media/imx/imx7-media-csi.c
++++ b/drivers/staging/media/imx/imx7-media-csi.c
+@@ -1009,6 +1009,7 @@ static int imx7_csi_try_fmt(struct imx7_csi *csi,
+               sdformat->format.width = in_fmt->width;
+               sdformat->format.height = in_fmt->height;
+               sdformat->format.code = in_fmt->code;
++              sdformat->format.field = in_fmt->field;
+               *cc = in_cc;
+               sdformat->format.colorspace = in_fmt->colorspace;
+@@ -1023,6 +1024,9 @@ static int imx7_csi_try_fmt(struct imx7_csi *csi,
+                                                        false);
+                       sdformat->format.code = (*cc)->codes[0];
+               }
++
++              if (sdformat->format.field != V4L2_FIELD_INTERLACED)
++                      sdformat->format.field = V4L2_FIELD_NONE;
+               break;
+       default:
+               return -EINVAL;
+-- 
+2.20.1
+
diff --git a/queue-5.4/media-imx-imx7_mipi_csis-power-off-the-source-when-s.patch b/queue-5.4/media-imx-imx7_mipi_csis-power-off-the-source-when-s.patch
new file mode 100644 (file)
index 0000000..418de98
--- /dev/null
@@ -0,0 +1,39 @@
+From 7b429c0bf3d5885367957bf2f717e37cf984ec84 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 10 Mar 2020 17:06:24 +0100
+Subject: media: imx: imx7_mipi_csis: Power off the source when stopping
+ streaming
+
+From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+
+[ Upstream commit 770cbf89f90b0663499dbb3f03aa81b3322757ec ]
+
+The .s_stream() implementation incorrectly powers on the source when
+stopping the stream. Power it off instead.
+
+Fixes: 7807063b862b ("media: staging/imx7: add MIPI CSI-2 receiver subdev for i.MX7")
+Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+Reviewed-by: Rui Miguel Silva <rmfrfs@gmail.com>
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/staging/media/imx/imx7-mipi-csis.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/staging/media/imx/imx7-mipi-csis.c b/drivers/staging/media/imx/imx7-mipi-csis.c
+index e50b1f88e25b5..6f628195c4daa 100644
+--- a/drivers/staging/media/imx/imx7-mipi-csis.c
++++ b/drivers/staging/media/imx/imx7-mipi-csis.c
+@@ -579,7 +579,7 @@ static int mipi_csis_s_stream(struct v4l2_subdev *mipi_sd, int enable)
+               state->flags |= ST_STREAMING;
+       } else {
+               v4l2_subdev_call(state->src_sd, video, s_stream, 0);
+-              ret = v4l2_subdev_call(state->src_sd, core, s_power, 1);
++              ret = v4l2_subdev_call(state->src_sd, core, s_power, 0);
+               mipi_csis_stop_stream(state);
+               state->flags &= ~ST_STREAMING;
+               if (state->debug)
+-- 
+2.20.1
+
diff --git a/queue-5.4/media-rc-add-keymap-for-videostrong-kii-pro.patch b/queue-5.4/media-rc-add-keymap-for-videostrong-kii-pro.patch
new file mode 100644 (file)
index 0000000..b1d22e3
--- /dev/null
@@ -0,0 +1,139 @@
+From 5ecc5bd577e63f6e2bc0a560e608ad74db505d25 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 10 Jan 2020 17:25:45 +0100
+Subject: media: rc: add keymap for Videostrong KII Pro
+
+From: Mohammad Rasim <mohammad.rasim96@gmail.com>
+
+[ Upstream commit 30defecb98400575349a7d32f0526e1dc42ea83e ]
+
+This is an NEC remote control device shipped with the Videostrong KII Pro
+tv box as well as other devices from videostrong.
+
+Signed-off-by: Mohammad Rasim <mohammad.rasim96@gmail.com>
+Signed-off-by: Sean Young <sean@mess.org>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/media/rc/keymaps/Makefile             |  1 +
+ .../media/rc/keymaps/rc-videostrong-kii-pro.c | 83 +++++++++++++++++++
+ include/media/rc-map.h                        |  1 +
+ 3 files changed, 85 insertions(+)
+ create mode 100644 drivers/media/rc/keymaps/rc-videostrong-kii-pro.c
+
+diff --git a/drivers/media/rc/keymaps/Makefile b/drivers/media/rc/keymaps/Makefile
+index a56fc634d2d68..ea91a9afa6a02 100644
+--- a/drivers/media/rc/keymaps/Makefile
++++ b/drivers/media/rc/keymaps/Makefile
+@@ -117,6 +117,7 @@ obj-$(CONFIG_RC_MAP) += rc-adstech-dvb-t-pci.o \
+                       rc-videomate-m1f.o \
+                       rc-videomate-s350.o \
+                       rc-videomate-tv-pvr.o \
++                      rc-videostrong-kii-pro.o \
+                       rc-wetek-hub.o \
+                       rc-wetek-play2.o \
+                       rc-winfast.o \
+diff --git a/drivers/media/rc/keymaps/rc-videostrong-kii-pro.c b/drivers/media/rc/keymaps/rc-videostrong-kii-pro.c
+new file mode 100644
+index 0000000000000..414d4d231e7ed
+--- /dev/null
++++ b/drivers/media/rc/keymaps/rc-videostrong-kii-pro.c
+@@ -0,0 +1,83 @@
++// SPDX-License-Identifier: GPL-2.0+
++//
++// Copyright (C) 2019 Mohammad Rasim <mohammad.rasim96@gmail.com>
++
++#include <media/rc-map.h>
++#include <linux/module.h>
++
++//
++// Keytable for the Videostrong KII Pro STB remote control
++//
++
++static struct rc_map_table kii_pro[] = {
++      { 0x59, KEY_POWER },
++      { 0x19, KEY_MUTE },
++      { 0x42, KEY_RED },
++      { 0x40, KEY_GREEN },
++      { 0x00, KEY_YELLOW },
++      { 0x03, KEY_BLUE },
++      { 0x4a, KEY_BACK },
++      { 0x48, KEY_FORWARD },
++      { 0x08, KEY_PREVIOUSSONG},
++      { 0x0b, KEY_NEXTSONG},
++      { 0x46, KEY_PLAYPAUSE },
++      { 0x44, KEY_STOP },
++      { 0x1f, KEY_FAVORITES}, //KEY_F5?
++      { 0x04, KEY_PVR },
++      { 0x4d, KEY_EPG },
++      { 0x02, KEY_INFO },
++      { 0x09, KEY_SUBTITLE },
++      { 0x01, KEY_AUDIO },
++      { 0x0d, KEY_HOMEPAGE },
++      { 0x11, KEY_TV },       // DTV ?
++      { 0x06, KEY_UP },
++      { 0x5a, KEY_LEFT },
++      { 0x1a, KEY_ENTER },    // KEY_OK ?
++      { 0x1b, KEY_RIGHT },
++      { 0x16, KEY_DOWN },
++      { 0x45, KEY_MENU },
++      { 0x05, KEY_ESC },
++      { 0x13, KEY_VOLUMEUP },
++      { 0x17, KEY_VOLUMEDOWN },
++      { 0x58, KEY_APPSELECT },
++      { 0x12, KEY_VENDOR },   // mouse
++      { 0x55, KEY_PAGEUP },   // KEY_CHANNELUP ?
++      { 0x15, KEY_PAGEDOWN }, // KEY_CHANNELDOWN ?
++      { 0x52, KEY_1 },
++      { 0x50, KEY_2 },
++      { 0x10, KEY_3 },
++      { 0x56, KEY_4 },
++      { 0x54, KEY_5 },
++      { 0x14, KEY_6 },
++      { 0x4e, KEY_7 },
++      { 0x4c, KEY_8 },
++      { 0x0c, KEY_9 },
++      { 0x18, KEY_WWW },      // KEY_F7
++      { 0x0f, KEY_0 },
++      { 0x51, KEY_BACKSPACE },
++};
++
++static struct rc_map_list kii_pro_map = {
++      .map = {
++              .scan     = kii_pro,
++              .size     = ARRAY_SIZE(kii_pro),
++              .rc_proto = RC_PROTO_NEC,
++              .name     = RC_MAP_KII_PRO,
++      }
++};
++
++static int __init init_rc_map_kii_pro(void)
++{
++      return rc_map_register(&kii_pro_map);
++}
++
++static void __exit exit_rc_map_kii_pro(void)
++{
++      rc_map_unregister(&kii_pro_map);
++}
++
++module_init(init_rc_map_kii_pro)
++module_exit(exit_rc_map_kii_pro)
++
++MODULE_LICENSE("GPL");
++MODULE_AUTHOR("Mohammad Rasim <mohammad.rasim96@gmail.com>");
+diff --git a/include/media/rc-map.h b/include/media/rc-map.h
+index afd2ab31bdf2d..c2ef3906e1cd1 100644
+--- a/include/media/rc-map.h
++++ b/include/media/rc-map.h
+@@ -271,6 +271,7 @@ struct rc_map *rc_map_get(const char *name);
+ #define RC_MAP_VIDEOMATE_K100            "rc-videomate-k100"
+ #define RC_MAP_VIDEOMATE_S350            "rc-videomate-s350"
+ #define RC_MAP_VIDEOMATE_TV_PVR          "rc-videomate-tv-pvr"
++#define RC_MAP_KII_PRO                   "rc-videostrong-kii-pro"
+ #define RC_MAP_WETEK_HUB                 "rc-wetek-hub"
+ #define RC_MAP_WETEK_PLAY2               "rc-wetek-play2"
+ #define RC_MAP_WINFAST                   "rc-winfast"
+-- 
+2.20.1
+
diff --git a/queue-5.4/media-venus-hfi_parser-ignore-hevc-encoding-for-v1.patch b/queue-5.4/media-venus-hfi_parser-ignore-hevc-encoding-for-v1.patch
new file mode 100644 (file)
index 0000000..9bfc909
--- /dev/null
@@ -0,0 +1,40 @@
+From 29fe213e796378befde03ca08f44d431c5fd4e54 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 9 Dec 2019 20:16:52 +0100
+Subject: media: venus: hfi_parser: Ignore HEVC encoding for V1
+
+From: Stephan Gerhold <stephan@gerhold.net>
+
+[ Upstream commit c50cc6dc6c48300af63a6fbc71b647053c15fc80 ]
+
+Some older MSM8916 Venus firmware versions also seem to indicate
+support for encoding HEVC, even though they really can't.
+This will lead to errors later because hfi_session_init() fails
+in this case.
+
+HEVC is already ignored for "dec_codecs", so add the same for
+"enc_codecs" to make these old firmware versions work correctly.
+
+Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
+Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/media/platform/qcom/venus/hfi_parser.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/media/platform/qcom/venus/hfi_parser.c b/drivers/media/platform/qcom/venus/hfi_parser.c
+index 2293d936e49ca..7f515a4b9bd12 100644
+--- a/drivers/media/platform/qcom/venus/hfi_parser.c
++++ b/drivers/media/platform/qcom/venus/hfi_parser.c
+@@ -181,6 +181,7 @@ static void parse_codecs(struct venus_core *core, void *data)
+       if (IS_V1(core)) {
+               core->dec_codecs &= ~HFI_VIDEO_CODEC_HEVC;
+               core->dec_codecs &= ~HFI_VIDEO_CODEC_SPARK;
++              core->enc_codecs &= ~HFI_VIDEO_CODEC_HEVC;
+       }
+ }
+-- 
+2.20.1
+
diff --git a/queue-5.4/net-stmmac-platform-fix-misleading-interrupt-error-m.patch b/queue-5.4/net-stmmac-platform-fix-misleading-interrupt-error-m.patch
new file mode 100644 (file)
index 0000000..e786fb5
--- /dev/null
@@ -0,0 +1,56 @@
+From dca087b74837e270da6d3c7717b042e4449d4621 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 6 Mar 2020 17:38:48 +0100
+Subject: net: stmmac: platform: Fix misleading interrupt error msg
+
+From: Markus Fuchs <mklntf@gmail.com>
+
+[ Upstream commit fc191af1bb0d069dc7e981076e8b80af21f1e61d ]
+
+Not every stmmac based platform makes use of the eth_wake_irq or eth_lpi
+interrupts. Use the platform_get_irq_byname_optional variant for these
+interrupts, so no error message is displayed, if they can't be found.
+Rather print an information to hint something might be wrong to assist
+debugging on platforms which use these interrupts.
+
+Signed-off-by: Markus Fuchs <mklntf@gmail.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ .../net/ethernet/stmicro/stmmac/stmmac_platform.c  | 14 ++++++++++----
+ 1 file changed, 10 insertions(+), 4 deletions(-)
+
+diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+index 5150551c28be3..508325cc105d5 100644
+--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
++++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+@@ -663,16 +663,22 @@ int stmmac_get_platform_resources(struct platform_device *pdev,
+        * In case the wake up interrupt is not passed from the platform
+        * so the driver will continue to use the mac irq (ndev->irq)
+        */
+-      stmmac_res->wol_irq = platform_get_irq_byname(pdev, "eth_wake_irq");
++      stmmac_res->wol_irq =
++              platform_get_irq_byname_optional(pdev, "eth_wake_irq");
+       if (stmmac_res->wol_irq < 0) {
+               if (stmmac_res->wol_irq == -EPROBE_DEFER)
+                       return -EPROBE_DEFER;
++              dev_info(&pdev->dev, "IRQ eth_wake_irq not found\n");
+               stmmac_res->wol_irq = stmmac_res->irq;
+       }
+-      stmmac_res->lpi_irq = platform_get_irq_byname(pdev, "eth_lpi");
+-      if (stmmac_res->lpi_irq == -EPROBE_DEFER)
+-              return -EPROBE_DEFER;
++      stmmac_res->lpi_irq =
++              platform_get_irq_byname_optional(pdev, "eth_lpi");
++      if (stmmac_res->lpi_irq < 0) {
++              if (stmmac_res->lpi_irq == -EPROBE_DEFER)
++                      return -EPROBE_DEFER;
++              dev_info(&pdev->dev, "IRQ eth_lpi not found\n");
++      }
+       res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+       stmmac_res->addr = devm_ioremap_resource(&pdev->dev, res);
+-- 
+2.20.1
+
diff --git a/queue-5.4/net-vxge-fix-wrong-__va_args__-usage.patch b/queue-5.4/net-vxge-fix-wrong-__va_args__-usage.patch
new file mode 100644 (file)
index 0000000..0452224
--- /dev/null
@@ -0,0 +1,98 @@
+From ec933d7176eb41aaa1ae15688078e9c59bc80349 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 16 Mar 2020 22:23:47 +0800
+Subject: net: vxge: fix wrong __VA_ARGS__ usage
+
+From: Zheng Wei <wei.zheng@vivo.com>
+
+[ Upstream commit b317538c47943f9903860d83cc0060409e12d2ff ]
+
+printk in macro vxge_debug_ll uses __VA_ARGS__ without "##" prefix,
+it causes a build error when there is no variable
+arguments(e.g. only fmt is specified.).
+
+Signed-off-by: Zheng Wei <wei.zheng@vivo.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/neterion/vxge/vxge-config.h |  2 +-
+ drivers/net/ethernet/neterion/vxge/vxge-main.h   | 14 +++++++-------
+ 2 files changed, 8 insertions(+), 8 deletions(-)
+
+diff --git a/drivers/net/ethernet/neterion/vxge/vxge-config.h b/drivers/net/ethernet/neterion/vxge/vxge-config.h
+index e678ba379598e..628fa9b2f7416 100644
+--- a/drivers/net/ethernet/neterion/vxge/vxge-config.h
++++ b/drivers/net/ethernet/neterion/vxge/vxge-config.h
+@@ -2045,7 +2045,7 @@ vxge_hw_vpath_strip_fcs_check(struct __vxge_hw_device *hldev, u64 vpath_mask);
+       if ((level >= VXGE_ERR && VXGE_COMPONENT_LL & VXGE_DEBUG_ERR_MASK) ||  \
+           (level >= VXGE_TRACE && VXGE_COMPONENT_LL & VXGE_DEBUG_TRACE_MASK))\
+               if ((mask & VXGE_DEBUG_MASK) == mask)                          \
+-                      printk(fmt "\n", __VA_ARGS__);                         \
++                      printk(fmt "\n", ##__VA_ARGS__);                       \
+ } while (0)
+ #else
+ #define vxge_debug_ll(level, mask, fmt, ...)
+diff --git a/drivers/net/ethernet/neterion/vxge/vxge-main.h b/drivers/net/ethernet/neterion/vxge/vxge-main.h
+index 59a57ff5e96af..9c86f4f9cd424 100644
+--- a/drivers/net/ethernet/neterion/vxge/vxge-main.h
++++ b/drivers/net/ethernet/neterion/vxge/vxge-main.h
+@@ -452,49 +452,49 @@ int vxge_fw_upgrade(struct vxgedev *vdev, char *fw_name, int override);
+ #if (VXGE_DEBUG_LL_CONFIG & VXGE_DEBUG_MASK)
+ #define vxge_debug_ll_config(level, fmt, ...) \
+-      vxge_debug_ll(level, VXGE_DEBUG_LL_CONFIG, fmt, __VA_ARGS__)
++      vxge_debug_ll(level, VXGE_DEBUG_LL_CONFIG, fmt, ##__VA_ARGS__)
+ #else
+ #define vxge_debug_ll_config(level, fmt, ...)
+ #endif
+ #if (VXGE_DEBUG_INIT & VXGE_DEBUG_MASK)
+ #define vxge_debug_init(level, fmt, ...) \
+-      vxge_debug_ll(level, VXGE_DEBUG_INIT, fmt, __VA_ARGS__)
++      vxge_debug_ll(level, VXGE_DEBUG_INIT, fmt, ##__VA_ARGS__)
+ #else
+ #define vxge_debug_init(level, fmt, ...)
+ #endif
+ #if (VXGE_DEBUG_TX & VXGE_DEBUG_MASK)
+ #define vxge_debug_tx(level, fmt, ...) \
+-      vxge_debug_ll(level, VXGE_DEBUG_TX, fmt, __VA_ARGS__)
++      vxge_debug_ll(level, VXGE_DEBUG_TX, fmt, ##__VA_ARGS__)
+ #else
+ #define vxge_debug_tx(level, fmt, ...)
+ #endif
+ #if (VXGE_DEBUG_RX & VXGE_DEBUG_MASK)
+ #define vxge_debug_rx(level, fmt, ...) \
+-      vxge_debug_ll(level, VXGE_DEBUG_RX, fmt, __VA_ARGS__)
++      vxge_debug_ll(level, VXGE_DEBUG_RX, fmt, ##__VA_ARGS__)
+ #else
+ #define vxge_debug_rx(level, fmt, ...)
+ #endif
+ #if (VXGE_DEBUG_MEM & VXGE_DEBUG_MASK)
+ #define vxge_debug_mem(level, fmt, ...) \
+-      vxge_debug_ll(level, VXGE_DEBUG_MEM, fmt, __VA_ARGS__)
++      vxge_debug_ll(level, VXGE_DEBUG_MEM, fmt, ##__VA_ARGS__)
+ #else
+ #define vxge_debug_mem(level, fmt, ...)
+ #endif
+ #if (VXGE_DEBUG_ENTRYEXIT & VXGE_DEBUG_MASK)
+ #define vxge_debug_entryexit(level, fmt, ...) \
+-      vxge_debug_ll(level, VXGE_DEBUG_ENTRYEXIT, fmt, __VA_ARGS__)
++      vxge_debug_ll(level, VXGE_DEBUG_ENTRYEXIT, fmt, ##__VA_ARGS__)
+ #else
+ #define vxge_debug_entryexit(level, fmt, ...)
+ #endif
+ #if (VXGE_DEBUG_INTR & VXGE_DEBUG_MASK)
+ #define vxge_debug_intr(level, fmt, ...) \
+-      vxge_debug_ll(level, VXGE_DEBUG_INTR, fmt, __VA_ARGS__)
++      vxge_debug_ll(level, VXGE_DEBUG_INTR, fmt, ##__VA_ARGS__)
+ #else
+ #define vxge_debug_intr(level, fmt, ...)
+ #endif
+-- 
+2.20.1
+
diff --git a/queue-5.4/null_blk-fix-spurious-io-errors-after-failed-past-wp.patch b/queue-5.4/null_blk-fix-spurious-io-errors-after-failed-past-wp.patch
new file mode 100644 (file)
index 0000000..f1f9539
--- /dev/null
@@ -0,0 +1,55 @@
+From f190864ac24be9af6b7a2f092f917fe9321a0477 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 12 Feb 2020 23:23:20 +0300
+Subject: null_blk: fix spurious IO errors after failed past-wp access
+
+From: Alexey Dobriyan <adobriyan@gmail.com>
+
+[ Upstream commit ff77042296d0a54535ddf74412c5ae92cb4ec76a ]
+
+Steps to reproduce:
+
+       BLKRESETZONE zone 0
+
+       // force EIO
+       pwrite(fd, buf, 4096, 4096);
+
+       [issue more IO including zone ioctls]
+
+It will start failing randomly including IO to unrelated zones because of
+->error "reuse". Trigger can be partition detection as well if test is not
+run immediately which is even more entertaining.
+
+The fix is of course to clear ->error where necessary.
+
+Reviewed-by: Christoph Hellwig <hch@lst.de>
+Signed-off-by: Alexey Dobriyan (SK hynix) <adobriyan@gmail.com>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/block/null_blk_main.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/drivers/block/null_blk_main.c b/drivers/block/null_blk_main.c
+index 6603598b7bae9..c4454cfc6d530 100644
+--- a/drivers/block/null_blk_main.c
++++ b/drivers/block/null_blk_main.c
+@@ -579,6 +579,7 @@ static struct nullb_cmd *__alloc_cmd(struct nullb_queue *nq)
+       if (tag != -1U) {
+               cmd = &nq->cmds[tag];
+               cmd->tag = tag;
++              cmd->error = BLK_STS_OK;
+               cmd->nq = nq;
+               if (nq->dev->irqmode == NULL_IRQ_TIMER) {
+                       hrtimer_init(&cmd->timer, CLOCK_MONOTONIC,
+@@ -1335,6 +1336,7 @@ static blk_status_t null_queue_rq(struct blk_mq_hw_ctx *hctx,
+               cmd->timer.function = null_cmd_timer_expired;
+       }
+       cmd->rq = bd->rq;
++      cmd->error = BLK_STS_OK;
+       cmd->nq = nq;
+       blk_mq_start_request(bd->rq);
+-- 
+2.20.1
+
diff --git a/queue-5.4/null_blk-fix-the-null_add_dev-error-path.patch b/queue-5.4/null_blk-fix-the-null_add_dev-error-path.patch
new file mode 100644 (file)
index 0000000..6034a42
--- /dev/null
@@ -0,0 +1,97 @@
+From d64ba70b19cb62f3d12deb1e97aba58d689cc949 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 9 Mar 2020 21:26:21 -0700
+Subject: null_blk: Fix the null_add_dev() error path
+
+From: Bart Van Assche <bvanassche@acm.org>
+
+[ Upstream commit 2004bfdef945fe55196db6b9cdf321fbc75bb0de ]
+
+If null_add_dev() fails, clear dev->nullb.
+
+This patch fixes the following KASAN complaint:
+
+BUG: KASAN: use-after-free in nullb_device_submit_queues_store+0xcf/0x160 [null_blk]
+Read of size 8 at addr ffff88803280fc30 by task check/8409
+
+Call Trace:
+ dump_stack+0xa5/0xe6
+ print_address_description.constprop.0+0x26/0x260
+ __kasan_report.cold+0x7b/0x99
+ kasan_report+0x16/0x20
+ __asan_load8+0x58/0x90
+ nullb_device_submit_queues_store+0xcf/0x160 [null_blk]
+ configfs_write_file+0x1c4/0x250 [configfs]
+ __vfs_write+0x4c/0x90
+ vfs_write+0x145/0x2c0
+ ksys_write+0xd7/0x180
+ __x64_sys_write+0x47/0x50
+ do_syscall_64+0x6f/0x2f0
+ entry_SYSCALL_64_after_hwframe+0x49/0xbe
+RIP: 0033:0x7ff370926317
+Code: 64 89 02 48 c7 c0 ff ff ff ff eb bb 0f 1f 80 00 00 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24
+RSP: 002b:00007fff2dd2da48 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
+RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007ff370926317
+RDX: 0000000000000002 RSI: 0000559437ef23f0 RDI: 0000000000000001
+RBP: 0000559437ef23f0 R08: 000000000000000a R09: 0000000000000001
+R10: 0000559436703471 R11: 0000000000000246 R12: 0000000000000002
+R13: 00007ff370a006a0 R14: 00007ff370a014a0 R15: 00007ff370a008a0
+
+Allocated by task 8409:
+ save_stack+0x23/0x90
+ __kasan_kmalloc.constprop.0+0xcf/0xe0
+ kasan_kmalloc+0xd/0x10
+ kmem_cache_alloc_node_trace+0x129/0x4c0
+ null_add_dev+0x24a/0xe90 [null_blk]
+ nullb_device_power_store+0x1b6/0x270 [null_blk]
+ configfs_write_file+0x1c4/0x250 [configfs]
+ __vfs_write+0x4c/0x90
+ vfs_write+0x145/0x2c0
+ ksys_write+0xd7/0x180
+ __x64_sys_write+0x47/0x50
+ do_syscall_64+0x6f/0x2f0
+ entry_SYSCALL_64_after_hwframe+0x49/0xbe
+
+Freed by task 8409:
+ save_stack+0x23/0x90
+ __kasan_slab_free+0x112/0x160
+ kasan_slab_free+0x12/0x20
+ kfree+0xdf/0x250
+ null_add_dev+0xaf3/0xe90 [null_blk]
+ nullb_device_power_store+0x1b6/0x270 [null_blk]
+ configfs_write_file+0x1c4/0x250 [configfs]
+ __vfs_write+0x4c/0x90
+ vfs_write+0x145/0x2c0
+ ksys_write+0xd7/0x180
+ __x64_sys_write+0x47/0x50
+ do_syscall_64+0x6f/0x2f0
+ entry_SYSCALL_64_after_hwframe+0x49/0xbe
+
+Fixes: 2984c8684f96 ("nullb: factor disk parameters")
+Signed-off-by: Bart Van Assche <bvanassche@acm.org>
+Reviewed-by: Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com>
+Cc: Johannes Thumshirn <jth@kernel.org>
+Cc: Hannes Reinecke <hare@suse.com>
+Cc: Ming Lei <ming.lei@redhat.com>
+Cc: Christoph Hellwig <hch@infradead.org>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/block/null_blk_main.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/block/null_blk_main.c b/drivers/block/null_blk_main.c
+index 0e7da5015ccd5..0b504989d09d9 100644
+--- a/drivers/block/null_blk_main.c
++++ b/drivers/block/null_blk_main.c
+@@ -1736,6 +1736,7 @@ out_cleanup_queues:
+       cleanup_queues(nullb);
+ out_free_nullb:
+       kfree(nullb);
++      dev->nullb = NULL;
+ out:
+       return rv;
+ }
+-- 
+2.20.1
+
diff --git a/queue-5.4/null_blk-handle-null_add_dev-failures-properly.patch b/queue-5.4/null_blk-handle-null_add_dev-failures-properly.patch
new file mode 100644 (file)
index 0000000..75d18f1
--- /dev/null
@@ -0,0 +1,64 @@
+From 6450af43a9b98b6b8b534f638d324638842c2858 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 9 Mar 2020 21:26:22 -0700
+Subject: null_blk: Handle null_add_dev() failures properly
+
+From: Bart Van Assche <bvanassche@acm.org>
+
+[ Upstream commit 9b03b713082a31a5b90e0a893c72aa620e255c26 ]
+
+If null_add_dev() fails then null_del_dev() is called with a NULL argument.
+Make null_del_dev() handle this scenario correctly. This patch fixes the
+following KASAN complaint:
+
+null-ptr-deref in null_del_dev+0x28/0x280 [null_blk]
+Read of size 8 at addr 0000000000000000 by task find/1062
+
+Call Trace:
+ dump_stack+0xa5/0xe6
+ __kasan_report.cold+0x65/0x99
+ kasan_report+0x16/0x20
+ __asan_load8+0x58/0x90
+ null_del_dev+0x28/0x280 [null_blk]
+ nullb_group_drop_item+0x7e/0xa0 [null_blk]
+ client_drop_item+0x53/0x80 [configfs]
+ configfs_rmdir+0x395/0x4e0 [configfs]
+ vfs_rmdir+0xb6/0x220
+ do_rmdir+0x238/0x2c0
+ __x64_sys_unlinkat+0x75/0x90
+ do_syscall_64+0x6f/0x2f0
+ entry_SYSCALL_64_after_hwframe+0x49/0xbe
+
+Signed-off-by: Bart Van Assche <bvanassche@acm.org>
+Reviewed-by: Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com>
+Cc: Johannes Thumshirn <jth@kernel.org>
+Cc: Hannes Reinecke <hare@suse.com>
+Cc: Ming Lei <ming.lei@redhat.com>
+Cc: Christoph Hellwig <hch@infradead.org>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/block/null_blk_main.c | 7 ++++++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/block/null_blk_main.c b/drivers/block/null_blk_main.c
+index 0b504989d09d9..6603598b7bae9 100644
+--- a/drivers/block/null_blk_main.c
++++ b/drivers/block/null_blk_main.c
+@@ -1382,7 +1382,12 @@ static void cleanup_queues(struct nullb *nullb)
+ static void null_del_dev(struct nullb *nullb)
+ {
+-      struct nullb_device *dev = nullb->dev;
++      struct nullb_device *dev;
++
++      if (!nullb)
++              return;
++
++      dev = nullb->dev;
+       ida_simple_remove(&nullb_indexes, nullb->index);
+-- 
+2.20.1
+
diff --git a/queue-5.4/pci-switchtec-fix-init_completion-race-condition-wit.patch b/queue-5.4/pci-switchtec-fix-init_completion-race-condition-wit.patch
new file mode 100644 (file)
index 0000000..ffebc91
--- /dev/null
@@ -0,0 +1,52 @@
+From 75c4beb9714af25a7acfc776053b44115ffb482e Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 21 Mar 2020 12:25:45 +0100
+Subject: PCI/switchtec: Fix init_completion race condition with poll_wait()
+
+From: Logan Gunthorpe <logang@deltatee.com>
+
+[ Upstream commit efbdc769601f4d50018bf7ca50fc9f7c67392ece ]
+
+The call to init_completion() in mrpc_queue_cmd() can theoretically
+race with the call to poll_wait() in switchtec_dev_poll().
+
+  poll()                       write()
+    switchtec_dev_poll()         switchtec_dev_write()
+      poll_wait(&s->comp.wait);      mrpc_queue_cmd()
+                                      init_completion(&s->comp)
+                                        init_waitqueue_head(&s->comp.wait)
+
+To my knowledge, no one has hit this bug.
+
+Fix this by using reinit_completion() instead of init_completion() in
+mrpc_queue_cmd().
+
+Fixes: 080b47def5e5 ("MicroSemi Switchtec management interface driver")
+
+Reported-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
+Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Acked-by: Bjorn Helgaas <bhelgaas@google.com>
+Link: https://lkml.kernel.org/r/20200313183608.2646-1-logang@deltatee.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/pci/switch/switchtec.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/pci/switch/switchtec.c b/drivers/pci/switch/switchtec.c
+index cc43c855452f7..2c9c3061894b2 100644
+--- a/drivers/pci/switch/switchtec.c
++++ b/drivers/pci/switch/switchtec.c
+@@ -175,7 +175,7 @@ static int mrpc_queue_cmd(struct switchtec_user *stuser)
+       kref_get(&stuser->kref);
+       stuser->read_len = sizeof(stuser->data);
+       stuser_set_state(stuser, MRPC_QUEUED);
+-      init_completion(&stuser->comp);
++      reinit_completion(&stuser->comp);
+       list_add_tail(&stuser->list, &stdev->mrpc_queue);
+       mrpc_cmd_submit(stdev);
+-- 
+2.20.1
+
diff --git a/queue-5.4/pstore-platform-fix-potential-mem-leak-if-pstore_ini.patch b/queue-5.4/pstore-platform-fix-potential-mem-leak-if-pstore_ini.patch
new file mode 100644 (file)
index 0000000..40e87e5
--- /dev/null
@@ -0,0 +1,41 @@
+From d4c9afd04cd864125894c8750fc60290c63bde9e Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 7 Feb 2020 17:46:39 +0800
+Subject: pstore/platform: fix potential mem leak if pstore_init_fs failed
+
+From: chenqiwu <chenqiwu@xiaomi.com>
+
+[ Upstream commit 8a57d6d4ddfa41c49014e20493152c41a38fcbf8 ]
+
+There is a potential mem leak when pstore_init_fs failed,
+since the pstore compression maybe unlikey to initialized
+successfully. We must clean up the allocation once this
+unlikey issue happens.
+
+Signed-off-by: chenqiwu <chenqiwu@xiaomi.com>
+Link: https://lore.kernel.org/r/1581068800-13817-1-git-send-email-qiwuchen55@gmail.com
+Signed-off-by: Kees Cook <keescook@chromium.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/pstore/platform.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/fs/pstore/platform.c b/fs/pstore/platform.c
+index 3d7024662d295..cdf5b8ae2583c 100644
+--- a/fs/pstore/platform.c
++++ b/fs/pstore/platform.c
+@@ -823,9 +823,9 @@ static int __init pstore_init(void)
+       ret = pstore_init_fs();
+       if (ret)
+-              return ret;
++              free_buf_for_compression();
+-      return 0;
++      return ret;
+ }
+ late_initcall(pstore_init);
+-- 
+2.20.1
+
diff --git a/queue-5.4/qlcnic-fix-bad-kzalloc-null-test.patch b/queue-5.4/qlcnic-fix-bad-kzalloc-null-test.patch
new file mode 100644 (file)
index 0000000..4d2b67a
--- /dev/null
@@ -0,0 +1,35 @@
+From 497abe5fa125b9bf3f706ab9e06f3a5034940225 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 26 Mar 2020 18:14:29 +0800
+Subject: qlcnic: Fix bad kzalloc null test
+
+From: Xu Wang <vulab@iscas.ac.cn>
+
+[ Upstream commit bcaeb886ade124331a6f3a5cef34a3f1484c0a03 ]
+
+In qlcnic_83xx_get_reset_instruction_template, the variable
+of null test is bad, so correct it.
+
+Signed-off-by: Xu Wang <vulab@iscas.ac.cn>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_init.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_init.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_init.c
+index 07f9067affc65..cda5b0a9e9489 100644
+--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_init.c
++++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_init.c
+@@ -1720,7 +1720,7 @@ static int qlcnic_83xx_get_reset_instruction_template(struct qlcnic_adapter *p_d
+       ahw->reset.seq_error = 0;
+       ahw->reset.buff = kzalloc(QLC_83XX_RESTART_TEMPLATE_SIZE, GFP_KERNEL);
+-      if (p_dev->ahw->reset.buff == NULL)
++      if (ahw->reset.buff == NULL)
+               return -ENOMEM;
+       p_buff = p_dev->ahw->reset.buff;
+-- 
+2.20.1
+
diff --git a/queue-5.4/rxrpc-abstract-out-the-calculation-of-whether-there-.patch b/queue-5.4/rxrpc-abstract-out-the-calculation-of-whether-there-.patch
new file mode 100644 (file)
index 0000000..c406f23
--- /dev/null
@@ -0,0 +1,80 @@
+From b0d6b236bf62f8cf56b46680df6eaddcdd915024 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 13 Mar 2020 09:05:38 +0000
+Subject: rxrpc: Abstract out the calculation of whether there's Tx space
+
+From: David Howells <dhowells@redhat.com>
+
+[ Upstream commit 158fe6665389964a1de212818b4a5c52b7f7aff4 ]
+
+Abstract out the calculation of there being sufficient Tx buffer space.
+This is reproduced several times in the rxrpc sendmsg code.
+
+Signed-off-by: David Howells <dhowells@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/rxrpc/sendmsg.c | 27 ++++++++++++++++++---------
+ 1 file changed, 18 insertions(+), 9 deletions(-)
+
+diff --git a/net/rxrpc/sendmsg.c b/net/rxrpc/sendmsg.c
+index 136eb465bfcb2..1cbd43eeda937 100644
+--- a/net/rxrpc/sendmsg.c
++++ b/net/rxrpc/sendmsg.c
+@@ -17,6 +17,21 @@
+ #include <net/af_rxrpc.h>
+ #include "ar-internal.h"
++/*
++ * Return true if there's sufficient Tx queue space.
++ */
++static bool rxrpc_check_tx_space(struct rxrpc_call *call, rxrpc_seq_t *_tx_win)
++{
++      unsigned int win_size =
++              min_t(unsigned int, call->tx_winsize,
++                    call->cong_cwnd + call->cong_extra);
++      rxrpc_seq_t tx_win = READ_ONCE(call->tx_hard_ack);
++
++      if (_tx_win)
++              *_tx_win = tx_win;
++      return call->tx_top - tx_win < win_size;
++}
++
+ /*
+  * Wait for space to appear in the Tx queue or a signal to occur.
+  */
+@@ -26,9 +41,7 @@ static int rxrpc_wait_for_tx_window_intr(struct rxrpc_sock *rx,
+ {
+       for (;;) {
+               set_current_state(TASK_INTERRUPTIBLE);
+-              if (call->tx_top - call->tx_hard_ack <
+-                  min_t(unsigned int, call->tx_winsize,
+-                        call->cong_cwnd + call->cong_extra))
++              if (rxrpc_check_tx_space(call, NULL))
+                       return 0;
+               if (call->state >= RXRPC_CALL_COMPLETE)
+@@ -68,9 +81,7 @@ static int rxrpc_wait_for_tx_window_nonintr(struct rxrpc_sock *rx,
+               set_current_state(TASK_UNINTERRUPTIBLE);
+               tx_win = READ_ONCE(call->tx_hard_ack);
+-              if (call->tx_top - tx_win <
+-                  min_t(unsigned int, call->tx_winsize,
+-                        call->cong_cwnd + call->cong_extra))
++              if (rxrpc_check_tx_space(call, &tx_win))
+                       return 0;
+               if (call->state >= RXRPC_CALL_COMPLETE)
+@@ -302,9 +313,7 @@ static int rxrpc_send_data(struct rxrpc_sock *rx,
+                       _debug("alloc");
+-                      if (call->tx_top - call->tx_hard_ack >=
+-                          min_t(unsigned int, call->tx_winsize,
+-                                call->cong_cwnd + call->cong_extra)) {
++                      if (!rxrpc_check_tx_space(call, NULL)) {
+                               ret = -EAGAIN;
+                               if (msg->msg_flags & MSG_DONTWAIT)
+                                       goto maybe_error;
+-- 
+2.20.1
+
diff --git a/queue-5.4/rxrpc-fix-call-interruptibility-handling.patch b/queue-5.4/rxrpc-fix-call-interruptibility-handling.patch
new file mode 100644 (file)
index 0000000..ce1bd15
--- /dev/null
@@ -0,0 +1,255 @@
+From a33bca3475b754508c794501d382444f620a41f0 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 13 Mar 2020 09:22:09 +0000
+Subject: rxrpc: Fix call interruptibility handling
+
+From: David Howells <dhowells@redhat.com>
+
+[ Upstream commit e138aa7d3271ac1b0690ae2c9b04d51468dce1d6 ]
+
+Fix the interruptibility of kernel-initiated client calls so that they're
+either only interruptible when they're waiting for a call slot to come
+available or they're not interruptible at all.  Either way, they're not
+interruptible during transmission.
+
+This should help prevent StoreData calls from being interrupted when
+writeback is in progress.  It doesn't, however, handle interruption during
+the receive phase.
+
+Userspace-initiated calls are still interruptable.  After the signal has
+been handled, sendmsg() will return the amount of data copied out of the
+buffer and userspace can perform another sendmsg() call to continue
+transmission.
+
+Fixes: bc5e3a546d55 ("rxrpc: Use MSG_WAITALL to tell sendmsg() to temporarily ignore signals")
+Signed-off-by: David Howells <dhowells@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/afs/rxrpc.c          |  3 ++-
+ include/net/af_rxrpc.h  |  8 +++++++-
+ net/rxrpc/af_rxrpc.c    |  4 ++--
+ net/rxrpc/ar-internal.h |  4 ++--
+ net/rxrpc/call_object.c |  3 +--
+ net/rxrpc/conn_client.c | 13 +++++++++---
+ net/rxrpc/sendmsg.c     | 44 +++++++++++++++++++++++++++++++++--------
+ 7 files changed, 60 insertions(+), 19 deletions(-)
+
+diff --git a/fs/afs/rxrpc.c b/fs/afs/rxrpc.c
+index ef1d09f8920bd..52aa90fb4fbd9 100644
+--- a/fs/afs/rxrpc.c
++++ b/fs/afs/rxrpc.c
+@@ -414,7 +414,8 @@ void afs_make_call(struct afs_addr_cursor *ac, struct afs_call *call, gfp_t gfp)
+                                         afs_wake_up_async_call :
+                                         afs_wake_up_call_waiter),
+                                        call->upgrade,
+-                                       call->intr,
++                                       (call->intr ? RXRPC_PREINTERRUPTIBLE :
++                                        RXRPC_UNINTERRUPTIBLE),
+                                        call->debug_id);
+       if (IS_ERR(rxcall)) {
+               ret = PTR_ERR(rxcall);
+diff --git a/include/net/af_rxrpc.h b/include/net/af_rxrpc.h
+index 299240df79e4a..04e97bab6f28b 100644
+--- a/include/net/af_rxrpc.h
++++ b/include/net/af_rxrpc.h
+@@ -16,6 +16,12 @@ struct sock;
+ struct socket;
+ struct rxrpc_call;
++enum rxrpc_interruptibility {
++      RXRPC_INTERRUPTIBLE,    /* Call is interruptible */
++      RXRPC_PREINTERRUPTIBLE, /* Call can be cancelled whilst waiting for a slot */
++      RXRPC_UNINTERRUPTIBLE,  /* Call should not be interruptible at all */
++};
++
+ /*
+  * Debug ID counter for tracing.
+  */
+@@ -41,7 +47,7 @@ struct rxrpc_call *rxrpc_kernel_begin_call(struct socket *,
+                                          gfp_t,
+                                          rxrpc_notify_rx_t,
+                                          bool,
+-                                         bool,
++                                         enum rxrpc_interruptibility,
+                                          unsigned int);
+ int rxrpc_kernel_send_data(struct socket *, struct rxrpc_call *,
+                          struct msghdr *, size_t,
+diff --git a/net/rxrpc/af_rxrpc.c b/net/rxrpc/af_rxrpc.c
+index a293238fe1e7e..2921fc2767134 100644
+--- a/net/rxrpc/af_rxrpc.c
++++ b/net/rxrpc/af_rxrpc.c
+@@ -285,7 +285,7 @@ struct rxrpc_call *rxrpc_kernel_begin_call(struct socket *sock,
+                                          gfp_t gfp,
+                                          rxrpc_notify_rx_t notify_rx,
+                                          bool upgrade,
+-                                         bool intr,
++                                         enum rxrpc_interruptibility interruptibility,
+                                          unsigned int debug_id)
+ {
+       struct rxrpc_conn_parameters cp;
+@@ -310,7 +310,7 @@ struct rxrpc_call *rxrpc_kernel_begin_call(struct socket *sock,
+       memset(&p, 0, sizeof(p));
+       p.user_call_ID = user_call_ID;
+       p.tx_total_len = tx_total_len;
+-      p.intr = intr;
++      p.interruptibility = interruptibility;
+       memset(&cp, 0, sizeof(cp));
+       cp.local                = rx->local;
+diff --git a/net/rxrpc/ar-internal.h b/net/rxrpc/ar-internal.h
+index 394d18857979a..3eb1ab40ca5cb 100644
+--- a/net/rxrpc/ar-internal.h
++++ b/net/rxrpc/ar-internal.h
+@@ -489,7 +489,6 @@ enum rxrpc_call_flag {
+       RXRPC_CALL_BEGAN_RX_TIMER,      /* We began the expect_rx_by timer */
+       RXRPC_CALL_RX_HEARD,            /* The peer responded at least once to this call */
+       RXRPC_CALL_RX_UNDERRUN,         /* Got data underrun */
+-      RXRPC_CALL_IS_INTR,             /* The call is interruptible */
+       RXRPC_CALL_DISCONNECTED,        /* The call has been disconnected */
+ };
+@@ -598,6 +597,7 @@ struct rxrpc_call {
+       atomic_t                usage;
+       u16                     service_id;     /* service ID */
+       u8                      security_ix;    /* Security type */
++      enum rxrpc_interruptibility interruptibility; /* At what point call may be interrupted */
+       u32                     call_id;        /* call ID on connection  */
+       u32                     cid;            /* connection ID plus channel index */
+       int                     debug_id;       /* debug ID for printks */
+@@ -720,7 +720,7 @@ struct rxrpc_call_params {
+               u32             normal;         /* Max time since last call packet (msec) */
+       } timeouts;
+       u8                      nr_timeouts;    /* Number of timeouts specified */
+-      bool                    intr;           /* The call is interruptible */
++      enum rxrpc_interruptibility interruptibility; /* How is interruptible is the call? */
+ };
+ struct rxrpc_send_params {
+diff --git a/net/rxrpc/call_object.c b/net/rxrpc/call_object.c
+index c9f34b0a11df4..f07970207b544 100644
+--- a/net/rxrpc/call_object.c
++++ b/net/rxrpc/call_object.c
+@@ -237,8 +237,7 @@ struct rxrpc_call *rxrpc_new_client_call(struct rxrpc_sock *rx,
+               return call;
+       }
+-      if (p->intr)
+-              __set_bit(RXRPC_CALL_IS_INTR, &call->flags);
++      call->interruptibility = p->interruptibility;
+       call->tx_total_len = p->tx_total_len;
+       trace_rxrpc_call(call->debug_id, rxrpc_call_new_client,
+                        atomic_read(&call->usage),
+diff --git a/net/rxrpc/conn_client.c b/net/rxrpc/conn_client.c
+index ea7d4c21f8893..f2a1a5dbb5a7b 100644
+--- a/net/rxrpc/conn_client.c
++++ b/net/rxrpc/conn_client.c
+@@ -655,13 +655,20 @@ static int rxrpc_wait_for_channel(struct rxrpc_call *call, gfp_t gfp)
+               add_wait_queue_exclusive(&call->waitq, &myself);
+               for (;;) {
+-                      if (test_bit(RXRPC_CALL_IS_INTR, &call->flags))
++                      switch (call->interruptibility) {
++                      case RXRPC_INTERRUPTIBLE:
++                      case RXRPC_PREINTERRUPTIBLE:
+                               set_current_state(TASK_INTERRUPTIBLE);
+-                      else
++                              break;
++                      case RXRPC_UNINTERRUPTIBLE:
++                      default:
+                               set_current_state(TASK_UNINTERRUPTIBLE);
++                              break;
++                      }
+                       if (call->call_id)
+                               break;
+-                      if (test_bit(RXRPC_CALL_IS_INTR, &call->flags) &&
++                      if ((call->interruptibility == RXRPC_INTERRUPTIBLE ||
++                           call->interruptibility == RXRPC_PREINTERRUPTIBLE) &&
+                           signal_pending(current)) {
+                               ret = -ERESTARTSYS;
+                               break;
+diff --git a/net/rxrpc/sendmsg.c b/net/rxrpc/sendmsg.c
+index 1cbd43eeda937..0fcf157aa09f8 100644
+--- a/net/rxrpc/sendmsg.c
++++ b/net/rxrpc/sendmsg.c
+@@ -62,7 +62,7 @@ static int rxrpc_wait_for_tx_window_intr(struct rxrpc_sock *rx,
+  * Wait for space to appear in the Tx queue uninterruptibly, but with
+  * a timeout of 2*RTT if no progress was made and a signal occurred.
+  */
+-static int rxrpc_wait_for_tx_window_nonintr(struct rxrpc_sock *rx,
++static int rxrpc_wait_for_tx_window_waitall(struct rxrpc_sock *rx,
+                                           struct rxrpc_call *call)
+ {
+       rxrpc_seq_t tx_start, tx_win;
+@@ -87,8 +87,7 @@ static int rxrpc_wait_for_tx_window_nonintr(struct rxrpc_sock *rx,
+               if (call->state >= RXRPC_CALL_COMPLETE)
+                       return call->error;
+-              if (test_bit(RXRPC_CALL_IS_INTR, &call->flags) &&
+-                  timeout == 0 &&
++              if (timeout == 0 &&
+                   tx_win == tx_start && signal_pending(current))
+                       return -EINTR;
+@@ -102,6 +101,26 @@ static int rxrpc_wait_for_tx_window_nonintr(struct rxrpc_sock *rx,
+       }
+ }
++/*
++ * Wait for space to appear in the Tx queue uninterruptibly.
++ */
++static int rxrpc_wait_for_tx_window_nonintr(struct rxrpc_sock *rx,
++                                          struct rxrpc_call *call,
++                                          long *timeo)
++{
++      for (;;) {
++              set_current_state(TASK_UNINTERRUPTIBLE);
++              if (rxrpc_check_tx_space(call, NULL))
++                      return 0;
++
++              if (call->state >= RXRPC_CALL_COMPLETE)
++                      return call->error;
++
++              trace_rxrpc_transmit(call, rxrpc_transmit_wait);
++              *timeo = schedule_timeout(*timeo);
++      }
++}
++
+ /*
+  * wait for space to appear in the transmit/ACK window
+  * - caller holds the socket locked
+@@ -119,10 +138,19 @@ static int rxrpc_wait_for_tx_window(struct rxrpc_sock *rx,
+       add_wait_queue(&call->waitq, &myself);
+-      if (waitall)
+-              ret = rxrpc_wait_for_tx_window_nonintr(rx, call);
+-      else
+-              ret = rxrpc_wait_for_tx_window_intr(rx, call, timeo);
++      switch (call->interruptibility) {
++      case RXRPC_INTERRUPTIBLE:
++              if (waitall)
++                      ret = rxrpc_wait_for_tx_window_waitall(rx, call);
++              else
++                      ret = rxrpc_wait_for_tx_window_intr(rx, call, timeo);
++              break;
++      case RXRPC_PREINTERRUPTIBLE:
++      case RXRPC_UNINTERRUPTIBLE:
++      default:
++              ret = rxrpc_wait_for_tx_window_nonintr(rx, call, timeo);
++              break;
++      }
+       remove_wait_queue(&call->waitq, &myself);
+       set_current_state(TASK_RUNNING);
+@@ -628,7 +656,7 @@ int rxrpc_do_sendmsg(struct rxrpc_sock *rx, struct msghdr *msg, size_t len)
+               .call.tx_total_len      = -1,
+               .call.user_call_ID      = 0,
+               .call.nr_timeouts       = 0,
+-              .call.intr              = true,
++              .call.interruptibility  = RXRPC_INTERRUPTIBLE,
+               .abort_code             = 0,
+               .command                = RXRPC_CMD_SEND_DATA,
+               .exclusive              = false,
+-- 
+2.20.1
+
diff --git a/queue-5.4/sched-avoid-scale-real-weight-down-to-zero.patch b/queue-5.4/sched-avoid-scale-real-weight-down-to-zero.patch
new file mode 100644 (file)
index 0000000..a4787f0
--- /dev/null
@@ -0,0 +1,82 @@
+From cac4d8277d83addee78489c4859ff2569f124a40 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 18 Mar 2020 10:15:15 +0800
+Subject: sched: Avoid scale real weight down to zero
+
+From: Michael Wang <yun.wang@linux.alibaba.com>
+
+[ Upstream commit 26cf52229efc87e2effa9d788f9b33c40fb3358a ]
+
+During our testing, we found a case that shares no longer
+working correctly, the cgroup topology is like:
+
+  /sys/fs/cgroup/cpu/A         (shares=102400)
+  /sys/fs/cgroup/cpu/A/B       (shares=2)
+  /sys/fs/cgroup/cpu/A/B/C     (shares=1024)
+
+  /sys/fs/cgroup/cpu/D         (shares=1024)
+  /sys/fs/cgroup/cpu/D/E       (shares=1024)
+  /sys/fs/cgroup/cpu/D/E/F     (shares=1024)
+
+The same benchmark is running in group C & F, no other tasks are
+running, the benchmark is capable to consumed all the CPUs.
+
+We suppose the group C will win more CPU resources since it could
+enjoy all the shares of group A, but it's F who wins much more.
+
+The reason is because we have group B with shares as 2, since
+A->cfs_rq.load.weight == B->se.load.weight == B->shares/nr_cpus,
+so A->cfs_rq.load.weight become very small.
+
+And in calc_group_shares() we calculate shares as:
+
+  load = max(scale_load_down(cfs_rq->load.weight), cfs_rq->avg.load_avg);
+  shares = (tg_shares * load) / tg_weight;
+
+Since the 'cfs_rq->load.weight' is too small, the load become 0
+after scale down, although 'tg_shares' is 102400, shares of the se
+which stand for group A on root cfs_rq become 2.
+
+While the se of D on root cfs_rq is far more bigger than 2, so it
+wins the battle.
+
+Thus when scale_load_down() scale real weight down to 0, it's no
+longer telling the real story, the caller will have the wrong
+information and the calculation will be buggy.
+
+This patch add check in scale_load_down(), so the real weight will
+be >= MIN_SHARES after scale, after applied the group C wins as
+expected.
+
+Suggested-by: Peter Zijlstra <peterz@infradead.org>
+Signed-off-by: Michael Wang <yun.wang@linux.alibaba.com>
+Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Reviewed-by: Vincent Guittot <vincent.guittot@linaro.org>
+Link: https://lkml.kernel.org/r/38e8e212-59a1-64b2-b247-b6d0b52d8dc1@linux.alibaba.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ kernel/sched/sched.h | 8 +++++++-
+ 1 file changed, 7 insertions(+), 1 deletion(-)
+
+diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
+index e5e2605778c97..c7e7481968bfa 100644
+--- a/kernel/sched/sched.h
++++ b/kernel/sched/sched.h
+@@ -118,7 +118,13 @@ extern long calc_load_fold_active(struct rq *this_rq, long adjust);
+ #ifdef CONFIG_64BIT
+ # define NICE_0_LOAD_SHIFT    (SCHED_FIXEDPOINT_SHIFT + SCHED_FIXEDPOINT_SHIFT)
+ # define scale_load(w)                ((w) << SCHED_FIXEDPOINT_SHIFT)
+-# define scale_load_down(w)   ((w) >> SCHED_FIXEDPOINT_SHIFT)
++# define scale_load_down(w) \
++({ \
++      unsigned long __w = (w); \
++      if (__w) \
++              __w = max(2UL, __w >> SCHED_FIXEDPOINT_SHIFT); \
++      __w; \
++})
+ #else
+ # define NICE_0_LOAD_SHIFT    (SCHED_FIXEDPOINT_SHIFT)
+ # define scale_load(w)                (w)
+-- 
+2.20.1
+
diff --git a/queue-5.4/selftests-net-add-definition-for-sol_dccp-to-fix-com.patch b/queue-5.4/selftests-net-add-definition-for-sol_dccp-to-fix-com.patch
new file mode 100644 (file)
index 0000000..86dbe4a
--- /dev/null
@@ -0,0 +1,47 @@
+From 04ad9bc068eb25744456983ca8396923e10897e6 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 18 Mar 2020 18:53:21 +0000
+Subject: selftests/net: add definition for SOL_DCCP to fix compilation errors
+ for old libc
+
+From: Alan Maguire <alan.maguire@oracle.com>
+
+[ Upstream commit 83a9b6f639e9f6b632337f9776de17d51d969c77 ]
+
+Many systems build/test up-to-date kernels with older libcs, and
+an older glibc (2.17) lacks the definition of SOL_DCCP in
+/usr/include/bits/socket.h (it was added in the 4.6 timeframe).
+
+Adding the definition to the test program avoids a compilation
+failure that gets in the way of building tools/testing/selftests/net.
+The test itself will work once the definition is added; either
+skipping due to DCCP not being configured in the kernel under test
+or passing, so there are no other more up-to-date glibc dependencies
+here it seems beyond that missing definition.
+
+Fixes: 11fb60d1089f ("selftests: net: reuseport_addr_any: add DCCP")
+Signed-off-by: Alan Maguire <alan.maguire@oracle.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ tools/testing/selftests/net/reuseport_addr_any.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+diff --git a/tools/testing/selftests/net/reuseport_addr_any.c b/tools/testing/selftests/net/reuseport_addr_any.c
+index c6233935fed14..b8475cb29be7a 100644
+--- a/tools/testing/selftests/net/reuseport_addr_any.c
++++ b/tools/testing/selftests/net/reuseport_addr_any.c
+@@ -21,6 +21,10 @@
+ #include <sys/socket.h>
+ #include <unistd.h>
++#ifndef SOL_DCCP
++#define SOL_DCCP 269
++#endif
++
+ static const char *IP4_ADDR = "127.0.0.1";
+ static const char *IP6_ADDR = "::1";
+ static const char *IP4_MAPPED6 = "::ffff:127.0.0.1";
+-- 
+2.20.1
+
diff --git a/queue-5.4/selftests-x86-ptrace_syscall_32-fix-no-vdso-segfault.patch b/queue-5.4/selftests-x86-ptrace_syscall_32-fix-no-vdso-segfault.patch
new file mode 100644 (file)
index 0000000..68c730c
--- /dev/null
@@ -0,0 +1,42 @@
+From 566443188dccfe7b77805e36cd4c301e517f88b4 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 12 Mar 2020 15:35:51 -0700
+Subject: selftests/x86/ptrace_syscall_32: Fix no-vDSO segfault
+
+From: Andy Lutomirski <luto@kernel.org>
+
+[ Upstream commit 630b99ab60aa972052a4202a1ff96c7e45eb0054 ]
+
+If AT_SYSINFO is not present, don't try to call a NULL pointer.
+
+Reported-by: kbuild test robot <lkp@intel.com>
+Signed-off-by: Andy Lutomirski <luto@kernel.org>
+Signed-off-by: Borislav Petkov <bp@suse.de>
+Link: https://lkml.kernel.org/r/faaf688265a7e1a5b944d6f8bc0f6368158306d3.1584052409.git.luto@kernel.org
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ tools/testing/selftests/x86/ptrace_syscall.c | 8 ++++++--
+ 1 file changed, 6 insertions(+), 2 deletions(-)
+
+diff --git a/tools/testing/selftests/x86/ptrace_syscall.c b/tools/testing/selftests/x86/ptrace_syscall.c
+index 6f22238f32173..12aaa063196e7 100644
+--- a/tools/testing/selftests/x86/ptrace_syscall.c
++++ b/tools/testing/selftests/x86/ptrace_syscall.c
+@@ -414,8 +414,12 @@ int main()
+ #if defined(__i386__) && (!defined(__GLIBC__) || __GLIBC__ > 2 || __GLIBC_MINOR__ >= 16)
+       vsyscall32 = (void *)getauxval(AT_SYSINFO);
+-      printf("[RUN]\tCheck AT_SYSINFO return regs\n");
+-      test_sys32_regs(do_full_vsyscall32);
++      if (vsyscall32) {
++              printf("[RUN]\tCheck AT_SYSINFO return regs\n");
++              test_sys32_regs(do_full_vsyscall32);
++      } else {
++              printf("[SKIP]\tAT_SYSINFO is not available\n");
++      }
+ #endif
+       test_ptrace_syscall_restart();
+-- 
+2.20.1
+
diff --git a/queue-5.4/series b/queue-5.4/series
new file mode 100644 (file)
index 0000000..d27a056
--- /dev/null
@@ -0,0 +1,68 @@
+arm-dts-sun8i-a83t-tbs-a711-hm5065-doesn-t-like-such.patch
+bus-sunxi-rsb-return-correct-data-when-mixing-16-bit.patch
+arm-dts-fix-dm814x-ethernet-by-changing-to-use-rgmii.patch
+bpf-fix-deadlock-with-rq_lock-in-bpf_send_signal.patch
+iwlwifi-mvm-fix-rate-scale-nss-configuration.patch
+input-tm2-touchkey-add-support-for-coreriver-tc360-v.patch
+soc-fsl-dpio-register-dpio-irq-handlers-after-dpio-c.patch
+rxrpc-abstract-out-the-calculation-of-whether-there-.patch
+rxrpc-fix-call-interruptibility-handling.patch
+net-stmmac-platform-fix-misleading-interrupt-error-m.patch
+net-vxge-fix-wrong-__va_args__-usage.patch
+hinic-fix-a-bug-of-waitting-for-io-stopped.patch
+hinic-fix-the-bug-of-clearing-event-queue.patch
+hinic-fix-out-of-order-excution-in-arm-cpu.patch
+hinic-fix-wrong-para-of-wait_for_completion_timeout.patch
+hinic-fix-wrong-value-of-min_skb_len.patch
+selftests-net-add-definition-for-sol_dccp-to-fix-com.patch
+cxgb4-ptp-pass-the-sign-of-offset-delta-in-fw-cmd.patch
+drm-scheduler-fix-rare-null-ptr-race.patch
+cfg80211-do-not-warn-on-same-channel-at-the-end-of-c.patch
+qlcnic-fix-bad-kzalloc-null-test.patch
+i2c-st-fix-missing-struct-parameter-description.patch
+i2c-pca-platform-use-platform_irq_get_optional.patch
+media-rc-add-keymap-for-videostrong-kii-pro.patch
+cpufreq-imx6q-fixes-unwanted-cpu-overclocking-on-i.m.patch
+staging-wilc1000-avoid-double-unlocking-of-wilc-hif_.patch
+media-venus-hfi_parser-ignore-hevc-encoding-for-v1.patch
+firmware-arm_sdei-fix-double-lock-on-hibernate-with-.patch
+null_blk-fix-the-null_add_dev-error-path.patch
+null_blk-handle-null_add_dev-failures-properly.patch
+null_blk-fix-spurious-io-errors-after-failed-past-wp.patch
+media-imx-imx7_mipi_csis-power-off-the-source-when-s.patch
+media-imx-imx7-media-csi-fix-video-field-handling.patch
+xhci-bail-out-early-if-driver-can-t-accress-host-in-.patch
+acpi-ec-do-not-clear-boot_ec_is_ecdt-in-acpi_ec_add.patch
+x86-don-t-let-pgprot_modify-change-the-page-encrypti.patch
+dma-mapping-fix-dma_pgprot-for-unencrypted-coherent-.patch
+block-keep-bdi-io_pages-in-sync-with-max_sectors_kb-.patch
+debugfs-check-module-state-before-warning-in-full-op.patch
+irqchip-versatile-fpga-handle-chained-irqs-properly.patch
+time-sched_clock-expire-timer-in-hardirq-context.patch
+media-allegro-fix-type-of-gop_length-in-channel_crea.patch
+sched-avoid-scale-real-weight-down-to-zero.patch
+selftests-x86-ptrace_syscall_32-fix-no-vdso-segfault.patch
+pci-switchtec-fix-init_completion-race-condition-wit.patch
+block-bfq-move-forward-the-getting-of-an-extra-ref-i.patch
+media-i2c-video-i2c-fix-build-errors-due-to-imply-hw.patch
+libata-remove-extra-scsi_host_put-in-ata_scsi_add_ho.patch
+pstore-platform-fix-potential-mem-leak-if-pstore_ini.patch
+gfs2-do-log_flush-in-gfs2_ail_empty_gl-even-if-ail-l.patch
+gfs2-don-t-demote-a-glock-until-its-revokes-are-writ.patch
+cpufreq-imx6q-fix-error-handling.patch
+x86-boot-use-unsigned-comparison-for-addresses.patch
+efi-x86-ignore-the-memory-attributes-table-on-i386.patch
+genirq-irqdomain-check-pointer-in-irq_domain_alloc_i.patch
+block-fix-use-after-free-issue-accessing-struct-io_c.patch
+media-i2c-ov5695-fix-power-on-and-off-sequences.patch
+usb-dwc3-core-add-support-for-disabling-ss-instances.patch
+irqchip-gic-v4-provide-irq_retrigger-to-avoid-circul.patch
+md-check-arrays-is-suspended-in-mddev_detach-before-.patch
+firmware-fix-a-double-abort-case-with-fw_load_sysfs_.patch
+spi-spi-fsl-dspi-replace-interruptible-wait-queue-wi.patch
+locking-lockdep-avoid-recursion-in-lockdep_count_-fo.patch
+block-bfq-fix-use-after-free-in-bfq_idle_slice_timer.patch
+btrfs-qgroup-ensure-qgroup_rescan_running-is-only-se.patch
+btrfs-remove-a-bug_on-from-merge_reloc_roots.patch
+btrfs-restart-relocate_tree_blocks-properly.patch
+btrfs-track-reloc-roots-based-on-their-commit-root-b.patch
diff --git a/queue-5.4/soc-fsl-dpio-register-dpio-irq-handlers-after-dpio-c.patch b/queue-5.4/soc-fsl-dpio-register-dpio-irq-handlers-after-dpio-c.patch
new file mode 100644 (file)
index 0000000..531339b
--- /dev/null
@@ -0,0 +1,152 @@
+From 19b6e74f1b4c2fb4f931b8549a3acf76f40c1bdc Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 10 Mar 2020 14:07:19 +0200
+Subject: soc: fsl: dpio: register dpio irq handlers after dpio create
+
+From: Grigore Popescu <grigore.popescu@nxp.com>
+
+[ Upstream commit fe8fe7723a3a824790bda681b40efd767e2251a7 ]
+
+The dpio irqs must be registered when you can actually
+receive interrupts, ie when the dpios are created.
+Kernel goes through NULL pointer dereference errors
+followed by kernel panic [1] because the dpio irqs are
+enabled before the dpio is created.
+
+[1]
+Unable to handle kernel NULL pointer dereference at virtual address 0040
+fsl_mc_dpio dpio.14: probed
+fsl_mc_dpio dpio.13: Adding to iommu group 11
+  ISV = 0, ISS = 0x00000004
+Unable to handle kernel NULL pointer dereference at virtual address 0040
+Mem abort info:
+  ESR = 0x96000004
+  EC = 0x25: DABT (current EL), IL = 32 bits
+  SET = 0, FnV = 0
+  EA = 0, S1PTW = 0
+Data abort info:
+  ISV = 0, ISS = 0x00000004
+  CM = 0, WnR = 0
+[0000000000000040] user address but active_mm is swapper
+Internal error: Oops: 96000004 [#1] PREEMPT SMP
+Modules linked in:
+CPU: 2 PID: 151 Comm: kworker/2:1 Not tainted 5.6.0-rc4-next-20200304 #1
+Hardware name: NXP Layerscape LX2160ARDB (DT)
+Workqueue: events deferred_probe_work_func
+pstate: 00000085 (nzcv daIf -PAN -UAO)
+pc : dpaa2_io_irq+0x18/0xe0
+lr : dpio_irq_handler+0x1c/0x28
+sp : ffff800010013e20
+x29: ffff800010013e20 x28: ffff0026d9b4c140
+x27: ffffa1d38a142018 x26: ffff0026d2953400
+x25: ffffa1d38a142018 x24: ffffa1d38a7ba1d8
+x23: ffff800010013f24 x22: 0000000000000000
+x21: 0000000000000072 x20: ffff0026d2953400
+x19: ffff0026d2a68b80 x18: 0000000000000001
+x17: 000000002fb37f3d x16: 0000000035eafadd
+x15: ffff0026d9b4c5b8 x14: ffffffffffffffff
+x13: ff00000000000000 x12: 0000000000000038
+x11: 0101010101010101 x10: 0000000000000040
+x9 : ffffa1d388db11e4 x8 : ffffa1d38a7e40f0
+x7 : ffff0026da414f38 x6 : 0000000000000000
+x5 : ffff0026da414d80 x4 : ffff5e5353d0c000
+x3 : ffff800010013f60 x2 : ffffa1d388db11c8
+x1 : ffff0026d2a67c00 x0 : 0000000000000000
+Call trace:
+ dpaa2_io_irq+0x18/0xe0
+ dpio_irq_handler+0x1c/0x28
+ __handle_irq_event_percpu+0x78/0x2c0
+ handle_irq_event_percpu+0x38/0x90
+ handle_irq_event+0x4c/0xd0
+ handle_fasteoi_irq+0xbc/0x168
+ generic_handle_irq+0x2c/0x40
+ __handle_domain_irq+0x68/0xc0
+ gic_handle_irq+0x64/0x150
+ el1_irq+0xb8/0x180
+ _raw_spin_unlock_irqrestore+0x14/0x48
+ irq_set_affinity_hint+0x6c/0xa0
+ dpaa2_dpio_probe+0x2a4/0x518
+ fsl_mc_driver_probe+0x28/0x70
+ really_probe+0xdc/0x320
+ driver_probe_device+0x5c/0xf0
+ __device_attach_driver+0x88/0xc0
+ bus_for_each_drv+0x7c/0xc8
+ __device_attach+0xe4/0x140
+ device_initial_probe+0x18/0x20
+ bus_probe_device+0x98/0xa0
+ device_add+0x41c/0x758
+ fsl_mc_device_add+0x184/0x530
+ dprc_scan_objects+0x280/0x370
+ dprc_probe+0x124/0x3b0
+ fsl_mc_driver_probe+0x28/0x70
+ really_probe+0xdc/0x320
+ driver_probe_device+0x5c/0xf0
+ __device_attach_driver+0x88/0xc0
+ bus_for_each_drv+0x7c/0xc8
+ __device_attach+0xe4/0x140
+ device_initial_probe+0x18/0x20
+ bus_probe_device+0x98/0xa0
+ deferred_probe_work_func+0x74/0xa8
+ process_one_work+0x1c8/0x470
+ worker_thread+0x1f8/0x428
+ kthread+0x124/0x128
+ ret_from_fork+0x10/0x18
+Code: a9bc7bfd 910003fd a9025bf5 a90363f7 (f9402015)
+---[ end trace 38298e1a29e7a570 ]---
+Kernel panic - not syncing: Fatal exception in interrupt
+SMP: stopping secondary CPUs
+Mem abort info:
+  ESR = 0x96000004
+  CM = 0, WnR = 0
+  EC = 0x25: DABT (current EL), IL = 32 bits
+[0000000000000040] user address but active_mm is swapper
+  SET = 0, FnV = 0
+  EA = 0, S1PTW = 0
+Data abort info:
+  ISV = 0, ISS = 0x00000004
+  CM = 0, WnR = 0
+[0000000000000040] user address but active_mm is swapper
+SMP: failed to stop secondary CPUs 0-2
+Kernel Offset: 0x21d378600000 from 0xffff800010000000
+PHYS_OFFSET: 0xffffe92180000000
+CPU features: 0x10002,21806008
+Memory Limit: none
+---[ end Kernel panic - not syncing: Fatal exception in interrupt ]---
+
+Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
+Signed-off-by: Grigore Popescu <grigore.popescu@nxp.com>
+Signed-off-by: Li Yang <leoyang.li@nxp.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/soc/fsl/dpio/dpio-driver.c | 8 ++++----
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+diff --git a/drivers/soc/fsl/dpio/dpio-driver.c b/drivers/soc/fsl/dpio/dpio-driver.c
+index 70014ecce2a7e..7b642c330977f 100644
+--- a/drivers/soc/fsl/dpio/dpio-driver.c
++++ b/drivers/soc/fsl/dpio/dpio-driver.c
+@@ -233,10 +233,6 @@ static int dpaa2_dpio_probe(struct fsl_mc_device *dpio_dev)
+               goto err_allocate_irqs;
+       }
+-      err = register_dpio_irq_handlers(dpio_dev, desc.cpu);
+-      if (err)
+-              goto err_register_dpio_irq;
+-
+       priv->io = dpaa2_io_create(&desc, dev);
+       if (!priv->io) {
+               dev_err(dev, "dpaa2_io_create failed\n");
+@@ -244,6 +240,10 @@ static int dpaa2_dpio_probe(struct fsl_mc_device *dpio_dev)
+               goto err_dpaa2_io_create;
+       }
++      err = register_dpio_irq_handlers(dpio_dev, desc.cpu);
++      if (err)
++              goto err_register_dpio_irq;
++
+       dev_info(dev, "probed\n");
+       dev_dbg(dev, "   receives_notifications = %d\n",
+               desc.receives_notifications);
+-- 
+2.20.1
+
diff --git a/queue-5.4/spi-spi-fsl-dspi-replace-interruptible-wait-queue-wi.patch b/queue-5.4/spi-spi-fsl-dspi-replace-interruptible-wait-queue-wi.patch
new file mode 100644 (file)
index 0000000..a518391
--- /dev/null
@@ -0,0 +1,177 @@
+From 1cfa132fd7876ae25e4cf0b89d7133f2deecffac Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 18 Mar 2020 02:15:57 +0200
+Subject: spi: spi-fsl-dspi: Replace interruptible wait queue with a simple
+ completion
+
+From: Vladimir Oltean <vladimir.oltean@nxp.com>
+
+[ Upstream commit 4f5ee75ea1718a09149460b3df993f389a67b56a ]
+
+Currently the driver puts the process in interruptible sleep waiting for
+the interrupt train to finish transfer to/from the tx_buf and rx_buf.
+
+But exiting the process with ctrl-c may make the kernel panic: the
+wait_event_interruptible call will return -ERESTARTSYS, which a proper
+driver implementation is perhaps supposed to handle, but nonetheless
+this one doesn't, and aborts the transfer altogether.
+
+Actually when the task is interrupted, there is still a high chance that
+the dspi_interrupt is still triggering. And if dspi_transfer_one_message
+returns execution all the way to the spi_device driver, that can free
+the spi_message and spi_transfer structures, leaving the interrupts to
+access a freed tx_buf and rx_buf.
+
+hexdump -C /dev/mtd0
+00000000  00 75 68 75 0a ff ff ff  ff ff ff ff ff ff ff ff
+|.uhu............|
+00000010  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
+|................|
+*
+^C[   38.495955] fsl-dspi 2120000.spi: Waiting for transfer to complete failed!
+[   38.503097] spi_master spi2: failed to transfer one message from queue
+[   38.509729] Unable to handle kernel paging request at virtual address ffff800095ab3377
+[   38.517676] Mem abort info:
+[   38.520474]   ESR = 0x96000045
+[   38.523533]   EC = 0x25: DABT (current EL), IL = 32 bits
+[   38.528861]   SET = 0, FnV = 0
+[   38.531921]   EA = 0, S1PTW = 0
+[   38.535067] Data abort info:
+[   38.537952]   ISV = 0, ISS = 0x00000045
+[   38.541797]   CM = 0, WnR = 1
+[   38.544771] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000082621000
+[   38.551494] [ffff800095ab3377] pgd=00000020fffff003, p4d=00000020fffff003, pud=0000000000000000
+[   38.560229] Internal error: Oops: 96000045 [#1] PREEMPT SMP
+[   38.565819] Modules linked in:
+[   38.568882] CPU: 0 PID: 2729 Comm: hexdump Not tainted 5.6.0-rc4-next-20200306-00052-gd8730cdc8a0b-dirty #193
+[   38.578834] Hardware name: Kontron SMARC-sAL28 (Single PHY) on SMARC Eval 2.0 carrier (DT)
+[   38.587129] pstate: 20000085 (nzCv daIf -PAN -UAO)
+[   38.591941] pc : ktime_get_real_ts64+0x3c/0x110
+[   38.596487] lr : spi_take_timestamp_pre+0x40/0x90
+[   38.601203] sp : ffff800010003d90
+[   38.604525] x29: ffff800010003d90 x28: ffff80001200e000
+[   38.609854] x27: ffff800011da9000 x26: ffff002079c40400
+[   38.615184] x25: ffff8000117fe018 x24: ffff800011daa1a0
+[   38.620513] x23: ffff800015ab3860 x22: ffff800095ab3377
+[   38.625841] x21: 000000000000146e x20: ffff8000120c3000
+[   38.631170] x19: ffff0020795f6e80 x18: ffff800011da9948
+[   38.636498] x17: 0000000000000000 x16: 0000000000000000
+[   38.641826] x15: ffff800095ab3377 x14: 0720072007200720
+[   38.647155] x13: 0720072007200765 x12: 0775076507750771
+[   38.652483] x11: 0720076d076f0772 x10: 0000000000000040
+[   38.657812] x9 : ffff8000108e2100 x8 : ffff800011dcabe8
+[   38.663139] x7 : 0000000000000000 x6 : ffff800015ab3a60
+[   38.668468] x5 : 0000000007200720 x4 : ffff800095ab3377
+[   38.673796] x3 : 0000000000000000 x2 : 0000000000000ab0
+[   38.679125] x1 : ffff800011daa000 x0 : 0000000000000026
+[   38.684454] Call trace:
+[   38.686905]  ktime_get_real_ts64+0x3c/0x110
+[   38.691100]  spi_take_timestamp_pre+0x40/0x90
+[   38.695470]  dspi_fifo_write+0x58/0x2c0
+[   38.699315]  dspi_interrupt+0xbc/0xd0
+[   38.702987]  __handle_irq_event_percpu+0x78/0x2c0
+[   38.707706]  handle_irq_event_percpu+0x3c/0x90
+[   38.712161]  handle_irq_event+0x4c/0xd0
+[   38.716008]  handle_fasteoi_irq+0xbc/0x170
+[   38.720115]  generic_handle_irq+0x2c/0x40
+[   38.724135]  __handle_domain_irq+0x68/0xc0
+[   38.728243]  gic_handle_irq+0xc8/0x160
+[   38.732000]  el1_irq+0xb8/0x180
+[   38.735149]  spi_nor_spimem_read_data+0xe0/0x140
+[   38.739779]  spi_nor_read+0xc4/0x120
+[   38.743364]  mtd_read_oob+0xa8/0xc0
+[   38.746860]  mtd_read+0x4c/0x80
+[   38.750007]  mtdchar_read+0x108/0x2a0
+[   38.753679]  __vfs_read+0x20/0x50
+[   38.757002]  vfs_read+0xa4/0x190
+[   38.760237]  ksys_read+0x6c/0xf0
+[   38.763471]  __arm64_sys_read+0x20/0x30
+[   38.767319]  el0_svc_common.constprop.3+0x90/0x160
+[   38.772125]  do_el0_svc+0x28/0x90
+[   38.775449]  el0_sync_handler+0x118/0x190
+[   38.779468]  el0_sync+0x140/0x180
+[   38.782793] Code: 91000294 1400000f d50339bf f9405e80 (f90002c0)
+[   38.788910] ---[ end trace 55da560db4d6bef7 ]---
+[   38.793540] Kernel panic - not syncing: Fatal exception in interrupt
+[   38.799914] SMP: stopping secondary CPUs
+[   38.803849] Kernel Offset: disabled
+[   38.807344] CPU features: 0x10002,20006008
+[   38.811451] Memory Limit: none
+[   38.814513] ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]---
+
+So it is clear that the "interruptible" part isn't handled correctly.
+When the process receives a signal, one could either attempt a clean
+abort (which appears to be difficult with this hardware) or just keep
+restarting the sleep until the wait queue really completes. But checking
+in a loop for -ERESTARTSYS is a bit too complicated for this driver, so
+just make the sleep uninterruptible, to avoid all that nonsense.
+
+The wait queue was actually restructured as a completion, after polling
+other drivers for the most "popular" approach.
+
+Fixes: 349ad66c0ab0 ("spi:Add Freescale DSPI driver for Vybrid VF610 platform")
+Reported-by: Michael Walle <michael@walle.cc>
+Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
+Tested-by: Michael Walle <michael@walle.cc>
+Link: https://lore.kernel.org/r/20200318001603.9650-7-olteanv@gmail.com
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/spi/spi-fsl-dspi.c | 19 ++++++-------------
+ 1 file changed, 6 insertions(+), 13 deletions(-)
+
+diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
+index d47bd26577b37..68e33457c814f 100644
+--- a/drivers/spi/spi-fsl-dspi.c
++++ b/drivers/spi/spi-fsl-dspi.c
+@@ -192,8 +192,7 @@ struct fsl_dspi {
+       u8                                      bytes_per_word;
+       const struct fsl_dspi_devtype_data      *devtype_data;
+-      wait_queue_head_t                       waitq;
+-      u32                                     waitflags;
++      struct completion                       xfer_done;
+       struct fsl_dspi_dma                     *dma;
+ };
+@@ -703,10 +702,8 @@ static irqreturn_t dspi_interrupt(int irq, void *dev_id)
+       if (!(spi_sr & (SPI_SR_EOQF | SPI_SR_TCFQF)))
+               return IRQ_NONE;
+-      if (dspi_rxtx(dspi) == 0) {
+-              dspi->waitflags = 1;
+-              wake_up_interruptible(&dspi->waitq);
+-      }
++      if (dspi_rxtx(dspi) == 0)
++              complete(&dspi->xfer_done);
+       return IRQ_HANDLED;
+ }
+@@ -800,13 +797,9 @@ static int dspi_transfer_one_message(struct spi_controller *ctlr,
+                               status = dspi_poll(dspi);
+                       } while (status == -EINPROGRESS);
+               } else if (trans_mode != DSPI_DMA_MODE) {
+-                      status = wait_event_interruptible(dspi->waitq,
+-                                                        dspi->waitflags);
+-                      dspi->waitflags = 0;
++                      wait_for_completion(&dspi->xfer_done);
++                      reinit_completion(&dspi->xfer_done);
+               }
+-              if (status)
+-                      dev_err(&dspi->pdev->dev,
+-                              "Waiting for transfer to complete failed!\n");
+               if (transfer->delay_usecs)
+                       udelay(transfer->delay_usecs);
+@@ -1122,7 +1115,7 @@ static int dspi_probe(struct platform_device *pdev)
+               goto out_clk_put;
+       }
+-      init_waitqueue_head(&dspi->waitq);
++      init_completion(&dspi->xfer_done);
+ poll_mode:
+       if (dspi->devtype_data->trans_mode == DSPI_DMA_MODE) {
+-- 
+2.20.1
+
diff --git a/queue-5.4/staging-wilc1000-avoid-double-unlocking-of-wilc-hif_.patch b/queue-5.4/staging-wilc1000-avoid-double-unlocking-of-wilc-hif_.patch
new file mode 100644 (file)
index 0000000..8822b08
--- /dev/null
@@ -0,0 +1,41 @@
+From 622a0fb0c3e022be3633604107e70e3ad06a08bf Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 21 Feb 2020 11:30:20 +0000
+Subject: staging: wilc1000: avoid double unlocking of 'wilc->hif_cs' mutex
+
+From: Ajay Singh <ajay.kathat@microchip.com>
+
+[ Upstream commit 6c411581caef6e3b2c286871641018364c6db50a ]
+
+Possible double unlocking of 'wilc->hif_cs' mutex was identified by
+smatch [1]. Removed the extra call to release_bus() in
+wilc_wlan_handle_txq() which was missed in earlier commit fdc2ac1aafc6
+("staging: wilc1000: support suspend/resume functionality").
+
+[1]. https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org/thread/NOEVW7C3GV74EWXJO3XX6VT2NKVB2HMT/
+
+Reported-by: kbuild test robot <lkp@intel.com>
+Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
+Signed-off-by: Ajay Singh <ajay.kathat@microchip.com>
+Link: https://lore.kernel.org/r/20200221170120.15739-1-ajay.kathat@microchip.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/staging/wilc1000/wilc_wlan.c | 1 -
+ 1 file changed, 1 deletion(-)
+
+diff --git a/drivers/staging/wilc1000/wilc_wlan.c b/drivers/staging/wilc1000/wilc_wlan.c
+index 771d8cb68dc17..02f551536e18b 100644
+--- a/drivers/staging/wilc1000/wilc_wlan.c
++++ b/drivers/staging/wilc1000/wilc_wlan.c
+@@ -578,7 +578,6 @@ int wilc_wlan_handle_txq(struct wilc *wilc, u32 *txq_count)
+                               entries = ((reg >> 3) & 0x3f);
+                               break;
+                       }
+-                      release_bus(wilc, WILC_BUS_RELEASE_ALLOW_SLEEP);
+               } while (--timeout);
+               if (timeout <= 0) {
+                       ret = func->hif_write_reg(wilc, WILC_HOST_VMM_CTL, 0x0);
+-- 
+2.20.1
+
diff --git a/queue-5.4/time-sched_clock-expire-timer-in-hardirq-context.patch b/queue-5.4/time-sched_clock-expire-timer-in-hardirq-context.patch
new file mode 100644 (file)
index 0000000..c6bcbf8
--- /dev/null
@@ -0,0 +1,65 @@
+From b191e59119805073bcf396f6ef36c154f939dd08 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 9 Mar 2020 18:15:29 +0000
+Subject: time/sched_clock: Expire timer in hardirq context
+
+From: Ahmed S. Darwish <a.darwish@linutronix.de>
+
+[ Upstream commit 2c8bd58812ee3dbf0d78b566822f7eacd34bdd7b ]
+
+To minimize latency, PREEMPT_RT kernels expires hrtimers in preemptible
+softirq context by default. This can be overriden by marking the timer's
+expiry with HRTIMER_MODE_HARD.
+
+sched_clock_timer is missing this annotation: if its callback is preempted
+and the duration of the preemption exceeds the wrap around time of the
+underlying clocksource, sched clock will get out of sync.
+
+Mark the sched_clock_timer for expiry in hard interrupt context.
+
+Signed-off-by: Ahmed S. Darwish <a.darwish@linutronix.de>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Link: https://lkml.kernel.org/r/20200309181529.26558-1-a.darwish@linutronix.de
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ kernel/time/sched_clock.c | 9 +++++----
+ 1 file changed, 5 insertions(+), 4 deletions(-)
+
+diff --git a/kernel/time/sched_clock.c b/kernel/time/sched_clock.c
+index dbd69052eaa66..a5538dd76a819 100644
+--- a/kernel/time/sched_clock.c
++++ b/kernel/time/sched_clock.c
+@@ -207,7 +207,8 @@ sched_clock_register(u64 (*read)(void), int bits, unsigned long rate)
+       if (sched_clock_timer.function != NULL) {
+               /* update timeout for clock wrap */
+-              hrtimer_start(&sched_clock_timer, cd.wrap_kt, HRTIMER_MODE_REL);
++              hrtimer_start(&sched_clock_timer, cd.wrap_kt,
++                            HRTIMER_MODE_REL_HARD);
+       }
+       r = rate;
+@@ -251,9 +252,9 @@ void __init generic_sched_clock_init(void)
+        * Start the timer to keep sched_clock() properly updated and
+        * sets the initial epoch.
+        */
+-      hrtimer_init(&sched_clock_timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
++      hrtimer_init(&sched_clock_timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL_HARD);
+       sched_clock_timer.function = sched_clock_poll;
+-      hrtimer_start(&sched_clock_timer, cd.wrap_kt, HRTIMER_MODE_REL);
++      hrtimer_start(&sched_clock_timer, cd.wrap_kt, HRTIMER_MODE_REL_HARD);
+ }
+ /*
+@@ -290,7 +291,7 @@ void sched_clock_resume(void)
+       struct clock_read_data *rd = &cd.read_data[0];
+       rd->epoch_cyc = cd.actual_read_sched_clock();
+-      hrtimer_start(&sched_clock_timer, cd.wrap_kt, HRTIMER_MODE_REL);
++      hrtimer_start(&sched_clock_timer, cd.wrap_kt, HRTIMER_MODE_REL_HARD);
+       rd->read_sched_clock = cd.actual_read_sched_clock;
+ }
+-- 
+2.20.1
+
diff --git a/queue-5.4/usb-dwc3-core-add-support-for-disabling-ss-instances.patch b/queue-5.4/usb-dwc3-core-add-support-for-disabling-ss-instances.patch
new file mode 100644 (file)
index 0000000..7ec93f6
--- /dev/null
@@ -0,0 +1,99 @@
+From 5933d1283ad9c7e314556b952c1841fc01c8ae05 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 21 Feb 2020 10:15:31 +0100
+Subject: usb: dwc3: core: add support for disabling SS instances in park mode
+
+From: Neil Armstrong <narmstrong@baylibre.com>
+
+[ Upstream commit 7ba6b09fda5e0cb741ee56f3264665e0edc64822 ]
+
+In certain circumstances, the XHCI SuperSpeed instance in park mode
+can fail to recover, thus on Amlogic G12A/G12B/SM1 SoCs when there is high
+load on the single XHCI SuperSpeed instance, the controller can crash like:
+ xhci-hcd xhci-hcd.0.auto: xHCI host not responding to stop endpoint command.
+ xhci-hcd xhci-hcd.0.auto: Host halt failed, -110
+ xhci-hcd xhci-hcd.0.auto: xHCI host controller not responding, assume dead
+ xhci-hcd xhci-hcd.0.auto: xHCI host not responding to stop endpoint command.
+ hub 2-1.1:1.0: hub_ext_port_status failed (err = -22)
+ xhci-hcd xhci-hcd.0.auto: HC died; cleaning up
+ usb 2-1.1-port1: cannot reset (err = -22)
+
+Setting the PARKMODE_DISABLE_SS bit in the DWC3_USB3_GUCTL1 mitigates
+the issue. The bit is described as :
+"When this bit is set to '1' all SS bus instances in park mode are disabled"
+
+Synopsys explains:
+The GUCTL1.PARKMODE_DISABLE_SS is only available in
+dwc_usb3 controller running in host mode.
+This should not be set for other IPs.
+This can be disabled by default based on IP, but I recommend to have a
+property to enable this feature for devices that need this.
+
+CC: Dongjin Kim <tobetter@gmail.com>
+Cc: Jianxin Pan <jianxin.pan@amlogic.com>
+Cc: Thinh Nguyen <thinhn@synopsys.com>
+Cc: Jun Li <lijun.kernel@gmail.com>
+Reported-by: Tim <elatllat@gmail.com>
+Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
+Signed-off-by: Felipe Balbi <balbi@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/usb/dwc3/core.c | 5 +++++
+ drivers/usb/dwc3/core.h | 4 ++++
+ 2 files changed, 9 insertions(+)
+
+diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
+index cede7a8e36055..526c275ad0bc5 100644
+--- a/drivers/usb/dwc3/core.c
++++ b/drivers/usb/dwc3/core.c
+@@ -992,6 +992,9 @@ static int dwc3_core_init(struct dwc3 *dwc)
+               if (dwc->dis_tx_ipgap_linecheck_quirk)
+                       reg |= DWC3_GUCTL1_TX_IPGAP_LINECHECK_DIS;
++              if (dwc->parkmode_disable_ss_quirk)
++                      reg |= DWC3_GUCTL1_PARKMODE_DISABLE_SS;
++
+               dwc3_writel(dwc->regs, DWC3_GUCTL1, reg);
+       }
+@@ -1305,6 +1308,8 @@ static void dwc3_get_properties(struct dwc3 *dwc)
+                               "snps,dis-del-phy-power-chg-quirk");
+       dwc->dis_tx_ipgap_linecheck_quirk = device_property_read_bool(dev,
+                               "snps,dis-tx-ipgap-linecheck-quirk");
++      dwc->parkmode_disable_ss_quirk = device_property_read_bool(dev,
++                              "snps,parkmode-disable-ss-quirk");
+       dwc->tx_de_emphasis_quirk = device_property_read_bool(dev,
+                               "snps,tx_de_emphasis_quirk");
+diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
+index 77c4a9abe3652..3ecc69c5b150f 100644
+--- a/drivers/usb/dwc3/core.h
++++ b/drivers/usb/dwc3/core.h
+@@ -249,6 +249,7 @@
+ #define DWC3_GUCTL_HSTINAUTORETRY     BIT(14)
+ /* Global User Control 1 Register */
++#define DWC3_GUCTL1_PARKMODE_DISABLE_SS       BIT(17)
+ #define DWC3_GUCTL1_TX_IPGAP_LINECHECK_DIS    BIT(28)
+ #define DWC3_GUCTL1_DEV_L1_EXIT_BY_HW BIT(24)
+@@ -1024,6 +1025,8 @@ struct dwc3_scratchpad_array {
+  *                    change quirk.
+  * @dis_tx_ipgap_linecheck_quirk: set if we disable u2mac linestate
+  *                    check during HS transmit.
++ * @parkmode_disable_ss_quirk: set if we need to disable all SuperSpeed
++ *                    instances in park mode.
+  * @tx_de_emphasis_quirk: set if we enable Tx de-emphasis quirk
+  * @tx_de_emphasis: Tx de-emphasis value
+  *    0       - -6dB de-emphasis
+@@ -1215,6 +1218,7 @@ struct dwc3 {
+       unsigned                dis_u2_freeclk_exists_quirk:1;
+       unsigned                dis_del_phy_power_chg_quirk:1;
+       unsigned                dis_tx_ipgap_linecheck_quirk:1;
++      unsigned                parkmode_disable_ss_quirk:1;
+       unsigned                tx_de_emphasis_quirk:1;
+       unsigned                tx_de_emphasis:2;
+-- 
+2.20.1
+
diff --git a/queue-5.4/x86-boot-use-unsigned-comparison-for-addresses.patch b/queue-5.4/x86-boot-use-unsigned-comparison-for-addresses.patch
new file mode 100644 (file)
index 0000000..e323b57
--- /dev/null
@@ -0,0 +1,71 @@
+From cc91cce37275a69f03cec0113ee1946c30c3f3f9 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 8 Mar 2020 09:08:44 +0100
+Subject: x86/boot: Use unsigned comparison for addresses
+
+From: Arvind Sankar <nivedita@alum.mit.edu>
+
+[ Upstream commit 81a34892c2c7c809f9c4e22c5ac936ae673fb9a2 ]
+
+The load address is compared with LOAD_PHYSICAL_ADDR using a signed
+comparison currently (using jge instruction).
+
+When loading a 64-bit kernel using the new efi32_pe_entry() point added by:
+
+  97aa276579b2 ("efi/x86: Add true mixed mode entry point into .compat section")
+
+using Qemu with -m 3072, the firmware actually loads us above 2Gb,
+resulting in a very early crash.
+
+Use the JAE instruction to perform a unsigned comparison instead, as physical
+addresses should be considered unsigned.
+
+Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
+Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Link: https://lore.kernel.org/r/20200301230436.2246909-6-nivedita@alum.mit.edu
+Link: https://lore.kernel.org/r/20200308080859.21568-14-ardb@kernel.org
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/x86/boot/compressed/head_32.S | 2 +-
+ arch/x86/boot/compressed/head_64.S | 4 ++--
+ 2 files changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/arch/x86/boot/compressed/head_32.S b/arch/x86/boot/compressed/head_32.S
+index 5e30eaaf8576f..70ffce98c5683 100644
+--- a/arch/x86/boot/compressed/head_32.S
++++ b/arch/x86/boot/compressed/head_32.S
+@@ -106,7 +106,7 @@ ENTRY(startup_32)
+       notl    %eax
+       andl    %eax, %ebx
+       cmpl    $LOAD_PHYSICAL_ADDR, %ebx
+-      jge     1f
++      jae     1f
+ #endif
+       movl    $LOAD_PHYSICAL_ADDR, %ebx
+ 1:
+diff --git a/arch/x86/boot/compressed/head_64.S b/arch/x86/boot/compressed/head_64.S
+index e9a7f7cadb121..07d2002da642a 100644
+--- a/arch/x86/boot/compressed/head_64.S
++++ b/arch/x86/boot/compressed/head_64.S
+@@ -106,7 +106,7 @@ ENTRY(startup_32)
+       notl    %eax
+       andl    %eax, %ebx
+       cmpl    $LOAD_PHYSICAL_ADDR, %ebx
+-      jge     1f
++      jae     1f
+ #endif
+       movl    $LOAD_PHYSICAL_ADDR, %ebx
+ 1:
+@@ -297,7 +297,7 @@ ENTRY(startup_64)
+       notq    %rax
+       andq    %rax, %rbp
+       cmpq    $LOAD_PHYSICAL_ADDR, %rbp
+-      jge     1f
++      jae     1f
+ #endif
+       movq    $LOAD_PHYSICAL_ADDR, %rbp
+ 1:
+-- 
+2.20.1
+
diff --git a/queue-5.4/x86-don-t-let-pgprot_modify-change-the-page-encrypti.patch b/queue-5.4/x86-don-t-let-pgprot_modify-change-the-page-encrypti.patch
new file mode 100644 (file)
index 0000000..bb0eb16
--- /dev/null
@@ -0,0 +1,69 @@
+From 7fc4a66d90802d7154eed58ab55e44350e7690d4 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 4 Mar 2020 12:45:26 +0100
+Subject: x86: Don't let pgprot_modify() change the page encryption bit
+
+From: Thomas Hellstrom <thellstrom@vmware.com>
+
+[ Upstream commit 6db73f17c5f155dbcfd5e48e621c706270b84df0 ]
+
+When SEV or SME is enabled and active, vm_get_page_prot() typically
+returns with the encryption bit set. This means that users of
+pgprot_modify(, vm_get_page_prot()) (mprotect_fixup(), do_mmap()) end up
+with a value of vma->vm_pg_prot that is not consistent with the intended
+protection of the PTEs.
+
+This is also important for fault handlers that rely on the VMA
+vm_page_prot to set the page protection. Fix this by not allowing
+pgprot_modify() to change the encryption bit, similar to how it's done
+for PAT bits.
+
+Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
+Signed-off-by: Borislav Petkov <bp@suse.de>
+Reviewed-by: Dave Hansen <dave.hansen@linux.intel.com>
+Acked-by: Tom Lendacky <thomas.lendacky@amd.com>
+Link: https://lkml.kernel.org/r/20200304114527.3636-2-thomas_os@shipmail.org
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/x86/include/asm/pgtable.h       | 7 +++++--
+ arch/x86/include/asm/pgtable_types.h | 2 +-
+ 2 files changed, 6 insertions(+), 3 deletions(-)
+
+diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h
+index 0bc530c4eb134..1e6bb4c253342 100644
+--- a/arch/x86/include/asm/pgtable.h
++++ b/arch/x86/include/asm/pgtable.h
+@@ -624,12 +624,15 @@ static inline pmd_t pmd_modify(pmd_t pmd, pgprot_t newprot)
+       return __pmd(val);
+ }
+-/* mprotect needs to preserve PAT bits when updating vm_page_prot */
++/*
++ * mprotect needs to preserve PAT and encryption bits when updating
++ * vm_page_prot
++ */
+ #define pgprot_modify pgprot_modify
+ static inline pgprot_t pgprot_modify(pgprot_t oldprot, pgprot_t newprot)
+ {
+       pgprotval_t preservebits = pgprot_val(oldprot) & _PAGE_CHG_MASK;
+-      pgprotval_t addbits = pgprot_val(newprot);
++      pgprotval_t addbits = pgprot_val(newprot) & ~_PAGE_CHG_MASK;
+       return __pgprot(preservebits | addbits);
+ }
+diff --git a/arch/x86/include/asm/pgtable_types.h b/arch/x86/include/asm/pgtable_types.h
+index b5e49e6bac635..8267dd426b152 100644
+--- a/arch/x86/include/asm/pgtable_types.h
++++ b/arch/x86/include/asm/pgtable_types.h
+@@ -123,7 +123,7 @@
+  */
+ #define _PAGE_CHG_MASK        (PTE_PFN_MASK | _PAGE_PCD | _PAGE_PWT |         \
+                        _PAGE_SPECIAL | _PAGE_ACCESSED | _PAGE_DIRTY | \
+-                       _PAGE_SOFT_DIRTY | _PAGE_DEVMAP)
++                       _PAGE_SOFT_DIRTY | _PAGE_DEVMAP | _PAGE_ENC)
+ #define _HPAGE_CHG_MASK (_PAGE_CHG_MASK | _PAGE_PSE)
+ /*
+-- 
+2.20.1
+
diff --git a/queue-5.4/xhci-bail-out-early-if-driver-can-t-accress-host-in-.patch b/queue-5.4/xhci-bail-out-early-if-driver-can-t-accress-host-in-.patch
new file mode 100644 (file)
index 0000000..6b8d3eb
--- /dev/null
@@ -0,0 +1,45 @@
+From c97195107d78aa42bdd22fa40bd73fc394c01d07 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 12 Mar 2020 16:45:09 +0200
+Subject: xhci: bail out early if driver can't accress host in resume
+
+From: Mathias Nyman <mathias.nyman@linux.intel.com>
+
+[ Upstream commit 72ae194704da212e2ec312ab182a96799d070755 ]
+
+Bail out early if the xHC host needs to be reset at resume
+but driver can't access xHC PCI registers.
+
+If xhci driver already fails to reset the controller then there
+is no point in attempting to free, re-initialize, re-allocate and
+re-start the host. If failure to access the host is detected later,
+failing the resume, xhci interrupts will be double freed
+when remove is called.
+
+Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
+Link: https://lore.kernel.org/r/20200312144517.1593-2-mathias.nyman@linux.intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/usb/host/xhci.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
+index 9b3b1b16eafba..2f49a7b3ce854 100644
+--- a/drivers/usb/host/xhci.c
++++ b/drivers/usb/host/xhci.c
+@@ -1157,8 +1157,10 @@ int xhci_resume(struct xhci_hcd *xhci, bool hibernated)
+               xhci_dbg(xhci, "Stop HCD\n");
+               xhci_halt(xhci);
+               xhci_zero_64b_regs(xhci);
+-              xhci_reset(xhci);
++              retval = xhci_reset(xhci);
+               spin_unlock_irq(&xhci->lock);
++              if (retval)
++                      return retval;
+               xhci_cleanup_msix(xhci);
+               xhci_dbg(xhci, "// Disabling event ring interrupts\n");
+-- 
+2.20.1
+