From 3ec9e16f778b740c473101c986d0b82922174edc Mon Sep 17 00:00:00 2001 From: Sasha Levin Date: Mon, 13 Apr 2020 19:47:00 -0400 Subject: [PATCH] Fixes for 4.19 Signed-off-by: Sasha Levin --- ...3t-tbs-a711-hm5065-doesn-t-like-such.patch | 38 ++++ ...e-after-free-in-bfq_idle_slice_timer.patch | 178 ++++++++++++++++++ ...ter-free-issue-accessing-struct-io_c.patch | 115 +++++++++++ ...o_pages-in-sync-with-max_sectors_kb-.patch | 49 +++++ ...ure-qgroup_rescan_running-is-only-se.patch | 141 ++++++++++++++ ...move-a-bug_on-from-merge_reloc_roots.patch | 77 ++++++++ ...c-roots-based-on-their-commit-root-b.patch | 121 ++++++++++++ ...turn-correct-data-when-mixing-16-bit.patch | 65 +++++++ ...xes-unwanted-cpu-overclocking-on-i.m.patch | 44 +++++ ...s-the-sign-of-offset-delta-in-fw-cmd.patch | 36 ++++ ...-the-memory-attributes-table-on-i386.patch | 77 ++++++++ ...i-fix-double-lock-on-hibernate-with-.patch | 118 ++++++++++++ ...ouble-abort-case-with-fw_load_sysfs_.patch | 81 ++++++++ ...-check-pointer-in-irq_domain_alloc_i.patch | 66 +++++++ ...e-a-glock-until-its-revokes-are-writ.patch | 46 +++++ ...fix-a-bug-of-waitting-for-io-stopped.patch | 92 +++++++++ ...-para-of-wait_for_completion_timeout.patch | 60 ++++++ ...missing-struct-parameter-description.patch | 35 ++++ ...rovide-irq_retrigger-to-avoid-circul.patch | 146 ++++++++++++++ ...le-fpga-handle-chained-irqs-properly.patch | 69 +++++++ ...tra-scsi_host_put-in-ata_scsi_add_ho.patch | 158 ++++++++++++++++ ...avoid-recursion-in-lockdep_count_-fo.patch | 80 ++++++++ ...is-suspended-in-mddev_detach-before-.patch | 66 +++++++ ...v5695-fix-power-on-and-off-sequences.patch | 134 +++++++++++++ ...i2c-fix-build-errors-due-to-imply-hw.patch | 43 +++++ ...i_parser-ignore-hevc-encoding-for-v1.patch | 40 ++++ ...net-vxge-fix-wrong-__va_args__-usage.patch | 98 ++++++++++ ...rious-io-errors-after-failed-past-wp.patch | 55 ++++++ ..._blk-fix-the-null_add_dev-error-path.patch | 97 ++++++++++ ...andle-null_add_dev-failures-properly.patch | 64 +++++++ ...x-init_completion-race-condition-wit.patch | 52 +++++ ...fix-potential-mem-leak-if-pstore_ini.patch | 41 ++++ .../qlcnic-fix-bad-kzalloc-null-test.patch | 35 ++++ ...ut-the-calculation-of-whether-there-.patch | 80 ++++++++ ...avoid-scale-real-weight-down-to-zero.patch | 82 ++++++++ ...race_syscall_32-fix-no-vdso-segfault.patch | 42 +++++ queue-4.19/series | 40 ++++ ...d-support-for-disabling-ss-instances.patch | 99 ++++++++++ ...se-unsigned-comparison-for-addresses.patch | 71 +++++++ ...prot_modify-change-the-page-encrypti.patch | 69 +++++++ ...rly-if-driver-can-t-accress-host-in-.patch | 45 +++++ 41 files changed, 3145 insertions(+) create mode 100644 queue-4.19/arm-dts-sun8i-a83t-tbs-a711-hm5065-doesn-t-like-such.patch create mode 100644 queue-4.19/block-bfq-fix-use-after-free-in-bfq_idle_slice_timer.patch create mode 100644 queue-4.19/block-fix-use-after-free-issue-accessing-struct-io_c.patch create mode 100644 queue-4.19/block-keep-bdi-io_pages-in-sync-with-max_sectors_kb-.patch create mode 100644 queue-4.19/btrfs-qgroup-ensure-qgroup_rescan_running-is-only-se.patch create mode 100644 queue-4.19/btrfs-remove-a-bug_on-from-merge_reloc_roots.patch create mode 100644 queue-4.19/btrfs-track-reloc-roots-based-on-their-commit-root-b.patch create mode 100644 queue-4.19/bus-sunxi-rsb-return-correct-data-when-mixing-16-bit.patch create mode 100644 queue-4.19/cpufreq-imx6q-fixes-unwanted-cpu-overclocking-on-i.m.patch create mode 100644 queue-4.19/cxgb4-ptp-pass-the-sign-of-offset-delta-in-fw-cmd.patch create mode 100644 queue-4.19/efi-x86-ignore-the-memory-attributes-table-on-i386.patch create mode 100644 queue-4.19/firmware-arm_sdei-fix-double-lock-on-hibernate-with-.patch create mode 100644 queue-4.19/firmware-fix-a-double-abort-case-with-fw_load_sysfs_.patch create mode 100644 queue-4.19/genirq-irqdomain-check-pointer-in-irq_domain_alloc_i.patch create mode 100644 queue-4.19/gfs2-don-t-demote-a-glock-until-its-revokes-are-writ.patch create mode 100644 queue-4.19/hinic-fix-a-bug-of-waitting-for-io-stopped.patch create mode 100644 queue-4.19/hinic-fix-wrong-para-of-wait_for_completion_timeout.patch create mode 100644 queue-4.19/i2c-st-fix-missing-struct-parameter-description.patch create mode 100644 queue-4.19/irqchip-gic-v4-provide-irq_retrigger-to-avoid-circul.patch create mode 100644 queue-4.19/irqchip-versatile-fpga-handle-chained-irqs-properly.patch create mode 100644 queue-4.19/libata-remove-extra-scsi_host_put-in-ata_scsi_add_ho.patch create mode 100644 queue-4.19/locking-lockdep-avoid-recursion-in-lockdep_count_-fo.patch create mode 100644 queue-4.19/md-check-arrays-is-suspended-in-mddev_detach-before-.patch create mode 100644 queue-4.19/media-i2c-ov5695-fix-power-on-and-off-sequences.patch create mode 100644 queue-4.19/media-i2c-video-i2c-fix-build-errors-due-to-imply-hw.patch create mode 100644 queue-4.19/media-venus-hfi_parser-ignore-hevc-encoding-for-v1.patch create mode 100644 queue-4.19/net-vxge-fix-wrong-__va_args__-usage.patch create mode 100644 queue-4.19/null_blk-fix-spurious-io-errors-after-failed-past-wp.patch create mode 100644 queue-4.19/null_blk-fix-the-null_add_dev-error-path.patch create mode 100644 queue-4.19/null_blk-handle-null_add_dev-failures-properly.patch create mode 100644 queue-4.19/pci-switchtec-fix-init_completion-race-condition-wit.patch create mode 100644 queue-4.19/pstore-platform-fix-potential-mem-leak-if-pstore_ini.patch create mode 100644 queue-4.19/qlcnic-fix-bad-kzalloc-null-test.patch create mode 100644 queue-4.19/rxrpc-abstract-out-the-calculation-of-whether-there-.patch create mode 100644 queue-4.19/sched-avoid-scale-real-weight-down-to-zero.patch create mode 100644 queue-4.19/selftests-x86-ptrace_syscall_32-fix-no-vdso-segfault.patch create mode 100644 queue-4.19/series create mode 100644 queue-4.19/usb-dwc3-core-add-support-for-disabling-ss-instances.patch create mode 100644 queue-4.19/x86-boot-use-unsigned-comparison-for-addresses.patch create mode 100644 queue-4.19/x86-don-t-let-pgprot_modify-change-the-page-encrypti.patch create mode 100644 queue-4.19/xhci-bail-out-early-if-driver-can-t-accress-host-in-.patch diff --git a/queue-4.19/arm-dts-sun8i-a83t-tbs-a711-hm5065-doesn-t-like-such.patch b/queue-4.19/arm-dts-sun8i-a83t-tbs-a711-hm5065-doesn-t-like-such.patch new file mode 100644 index 00000000000..ff4eb92e208 --- /dev/null +++ b/queue-4.19/arm-dts-sun8i-a83t-tbs-a711-hm5065-doesn-t-like-such.patch @@ -0,0 +1,38 @@ +From 7f196ca764a24ceacabb1a9cf707a8d64ecd681a Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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 + +[ 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 +Signed-off-by: Maxime Ripard +Signed-off-by: Sasha Levin +--- + 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 49547a43cc90a..54cbdaf7ffdcc 100644 +--- a/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts ++++ b/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts +@@ -318,8 +318,8 @@ + }; + + ®_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-4.19/block-bfq-fix-use-after-free-in-bfq_idle_slice_timer.patch b/queue-4.19/block-bfq-fix-use-after-free-in-bfq_idle_slice_timer.patch new file mode 100644 index 00000000000..812a25b32b7 --- /dev/null +++ b/queue-4.19/block-bfq-fix-use-after-free-in-bfq_idle_slice_timer.patch @@ -0,0 +1,178 @@ +From b7917c476834a5087df1f456841d3a2c3d4fe1a0 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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 + +[ 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 +Reported-by: Wang Wang +Signed-off-by: Zhiqiang Liu +Signed-off-by: Feilong Lin +Signed-off-by: Jens Axboe +Signed-off-by: Sasha Levin +--- + 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 66b1ebc21ce4f..5198ed1b36690 100644 +--- a/block/bfq-iosched.c ++++ b/block/bfq-iosched.c +@@ -5156,20 +5156,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 +@@ -5214,7 +5222,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-4.19/block-fix-use-after-free-issue-accessing-struct-io_c.patch b/queue-4.19/block-fix-use-after-free-issue-accessing-struct-io_c.patch new file mode 100644 index 00000000000..94c2d62508c --- /dev/null +++ b/queue-4.19/block-fix-use-after-free-issue-accessing-struct-io_c.patch @@ -0,0 +1,115 @@ +From a3e002d0111a27136f6191b1ea646db3eb3c02a1 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 11 Mar 2020 16:07:50 +0530 +Subject: block: Fix use-after-free issue accessing struct io_cq + +From: Sahitya Tummala + +[ 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 +Co-developed-by: Pradeep P V K +Signed-off-by: Pradeep P V K +Signed-off-by: Jens Axboe +Signed-off-by: Sasha Levin +--- + 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 01580f88fcb39..4c810969c3e2f 100644 +--- a/block/blk-ioc.c ++++ b/block/blk-ioc.c +@@ -87,6 +87,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); + } + +@@ -230,15 +231,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-4.19/block-keep-bdi-io_pages-in-sync-with-max_sectors_kb-.patch b/queue-4.19/block-keep-bdi-io_pages-in-sync-with-max_sectors_kb-.patch new file mode 100644 index 00000000000..9230e30a206 --- /dev/null +++ b/queue-4.19/block-keep-bdi-io_pages-in-sync-with-max_sectors_kb-.patch @@ -0,0 +1,49 @@ +From 27ac31d83598ccc8653239cdc714a878005103d5 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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 + +[ 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 +Reviewed-by: Bob Liu +Signed-off-by: Konstantin Khlebnikov +Signed-off-by: Song Liu +Signed-off-by: Sasha Levin +--- + block/blk-settings.c | 3 +++ + 1 file changed, 3 insertions(+) + +diff --git a/block/blk-settings.c b/block/blk-settings.c +index be9b39caadbd2..01093b8f3e624 100644 +--- a/block/blk-settings.c ++++ b/block/blk-settings.c +@@ -717,6 +717,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-4.19/btrfs-qgroup-ensure-qgroup_rescan_running-is-only-se.patch b/queue-4.19/btrfs-qgroup-ensure-qgroup_rescan_running-is-only-se.patch new file mode 100644 index 00000000000..56f5e7485e4 --- /dev/null +++ b/queue-4.19/btrfs-qgroup-ensure-qgroup_rescan_running-is-only-se.patch @@ -0,0 +1,141 @@ +From a7ff65f819a3ed40805bacbac3d09501fc93e9dd Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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 + +[ 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 +[ Change subject and cause analyse, use a smaller fix ] +Signed-off-by: Qu Wenruo +Reviewed-by: David Sterba +Signed-off-by: David Sterba +Signed-off-by: Sasha Levin +--- + 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 0cd043f03081e..cbd40826f5dcf 100644 +--- a/fs/btrfs/qgroup.c ++++ b/fs/btrfs/qgroup.c +@@ -1032,6 +1032,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); + } +@@ -2906,7 +2907,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); +@@ -2972,8 +2972,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; + } +@@ -3009,9 +3012,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-4.19/btrfs-remove-a-bug_on-from-merge_reloc_roots.patch b/queue-4.19/btrfs-remove-a-bug_on-from-merge_reloc_roots.patch new file mode 100644 index 00000000000..ea2494e2eec --- /dev/null +++ b/queue-4.19/btrfs-remove-a-bug_on-from-merge_reloc_roots.patch @@ -0,0 +1,77 @@ +From 05ffdff54fedfa8f559fcaed8f6a23f627ac9657 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 4 Mar 2020 11:18:30 -0500 +Subject: btrfs: remove a BUG_ON() from merge_reloc_roots() + +From: Josef Bacik + +[ 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 +Signed-off-by: Josef Bacik +Signed-off-by: David Sterba +Signed-off-by: Sasha Levin +--- + 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 f98913061a40c..6f4cb2db3b1a0 100644 +--- a/fs/btrfs/relocation.c ++++ b/fs/btrfs/relocation.c +@@ -2434,7 +2434,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-4.19/btrfs-track-reloc-roots-based-on-their-commit-root-b.patch b/queue-4.19/btrfs-track-reloc-roots-based-on-their-commit-root-b.patch new file mode 100644 index 00000000000..265b3a8efca --- /dev/null +++ b/queue-4.19/btrfs-track-reloc-roots-based-on-their-commit-root-b.patch @@ -0,0 +1,121 @@ +From 4a77a313743f6150039b9ad43c2b83e135f366ef Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 13 Mar 2020 17:17:08 -0400 +Subject: btrfs: track reloc roots based on their commit root bytenr + +From: Josef Bacik + +[ 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 +Signed-off-by: David Sterba +Signed-off-by: Sasha Levin +--- + 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 6f4cb2db3b1a0..a7f9aa5f05aa5 100644 +--- a/fs/btrfs/relocation.c ++++ b/fs/btrfs/relocation.c +@@ -1253,7 +1253,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); +@@ -1284,10 +1284,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) +@@ -1305,7 +1306,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; +@@ -1314,7 +1315,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); +@@ -1326,7 +1327,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); +@@ -1471,6 +1472,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); +@@ -4599,11 +4601,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-4.19/bus-sunxi-rsb-return-correct-data-when-mixing-16-bit.patch b/queue-4.19/bus-sunxi-rsb-return-correct-data-when-mixing-16-bit.patch new file mode 100644 index 00000000000..f0c208755f4 --- /dev/null +++ b/queue-4.19/bus-sunxi-rsb-return-correct-data-when-mixing-16-bit.patch @@ -0,0 +1,65 @@ +From 2a2d86ca4fb02594bd9b4ed08bd404a25415576f Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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 + +[ 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 +Acked-by: Chen-Yu Tsai +Signed-off-by: Maxime Ripard +Signed-off-by: Sasha Levin +--- + 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 1b76d95859027..2ca2cc56bcef6 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-4.19/cpufreq-imx6q-fixes-unwanted-cpu-overclocking-on-i.m.patch b/queue-4.19/cpufreq-imx6q-fixes-unwanted-cpu-overclocking-on-i.m.patch new file mode 100644 index 00000000000..0aa588c8130 --- /dev/null +++ b/queue-4.19/cpufreq-imx6q-fixes-unwanted-cpu-overclocking-on-i.m.patch @@ -0,0 +1,44 @@ +From 62d8ce0a86ca49f865b76f426125b160fea6a0bd Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 11 Feb 2020 12:58:07 +0100 +Subject: cpufreq: imx6q: Fixes unwanted cpu overclocking on i.MX6ULL + +From: Christoph Niedermaier + +[ 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 +Signed-off-by: Viresh Kumar +Signed-off-by: Sasha Levin +--- + 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 d8c3595e90236..a0cbbdfc77359 100644 +--- a/drivers/cpufreq/imx6q-cpufreq.c ++++ b/drivers/cpufreq/imx6q-cpufreq.c +@@ -310,6 +310,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-4.19/cxgb4-ptp-pass-the-sign-of-offset-delta-in-fw-cmd.patch b/queue-4.19/cxgb4-ptp-pass-the-sign-of-offset-delta-in-fw-cmd.patch new file mode 100644 index 00000000000..00e625d51fe --- /dev/null +++ b/queue-4.19/cxgb4-ptp-pass-the-sign-of-offset-delta-in-fw-cmd.patch @@ -0,0 +1,36 @@ +From 3c386ac7db92b5aebe7530336c90947502c4dab7 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 24 Mar 2020 17:10:00 +0530 +Subject: cxgb4/ptp: pass the sign of offset delta in FW CMD + +From: Raju Rangoju + +[ 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 +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + 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 9f9d6cae39d55..758f2b8363282 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-4.19/efi-x86-ignore-the-memory-attributes-table-on-i386.patch b/queue-4.19/efi-x86-ignore-the-memory-attributes-table-on-i386.patch new file mode 100644 index 00000000000..e6322b23099 --- /dev/null +++ b/queue-4.19/efi-x86-ignore-the-memory-attributes-table-on-i386.patch @@ -0,0 +1,77 @@ +From d5bca8b027056bdadce56b798bcc754896bc2bee Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sun, 8 Mar 2020 09:08:51 +0100 +Subject: efi/x86: Ignore the memory attributes table on i386 + +From: Ard Biesheuvel + +[ 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 +Signed-off-by: Ard Biesheuvel +Signed-off-by: Ingo Molnar +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 +--- + 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 d54fca902e64f..f1e0a27152691 100644 +--- a/drivers/firmware/efi/efi.c ++++ b/drivers/firmware/efi/efi.c +@@ -572,7 +572,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-4.19/firmware-arm_sdei-fix-double-lock-on-hibernate-with-.patch b/queue-4.19/firmware-arm_sdei-fix-double-lock-on-hibernate-with-.patch new file mode 100644 index 00000000000..64bac0eab9d --- /dev/null +++ b/queue-4.19/firmware-arm_sdei-fix-double-lock-on-hibernate-with-.patch @@ -0,0 +1,118 @@ +From ccccd7e4b2db56e77036efa8775616b7df095e1b Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 21 Feb 2020 16:35:06 +0000 +Subject: firmware: arm_sdei: fix double-lock on hibernate with shared events + +From: James Morse + +[ 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 +Signed-off-by: James Morse +Signed-off-by: Catalin Marinas +Signed-off-by: Sasha Levin +--- + 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 c64c7da738297..05b528c7ed8fd 100644 +--- a/drivers/firmware/arm_sdei.c ++++ b/drivers/firmware/arm_sdei.c +@@ -489,11 +489,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); + +@@ -516,6 +511,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; +@@ -583,26 +583,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; + } +@@ -630,8 +619,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-4.19/firmware-fix-a-double-abort-case-with-fw_load_sysfs_.patch b/queue-4.19/firmware-fix-a-double-abort-case-with-fw_load_sysfs_.patch new file mode 100644 index 00000000000..e58ee52b873 --- /dev/null +++ b/queue-4.19/firmware-fix-a-double-abort-case-with-fw_load_sysfs_.patch @@ -0,0 +1,81 @@ +From 5a219c4bae31bbc26846a3741de48ddb1767183f Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 3 Mar 2020 10:36:08 +0800 +Subject: firmware: fix a double abort case with fw_load_sysfs_fallback + +From: Junyong Sun + +[ 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 +Acked-by: Luis Chamberlain +Link: https://lore.kernel.org/r/1583202968-28792-1-git-send-email-sunjunyong@xiaomi.com +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Sasha Levin +--- + 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 818d8c37d70a9..3b7b748c4d4f2 100644 +--- a/drivers/base/firmware_loader/fallback.c ++++ b/drivers/base/firmware_loader/fallback.c +@@ -572,7 +572,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-4.19/genirq-irqdomain-check-pointer-in-irq_domain_alloc_i.patch b/queue-4.19/genirq-irqdomain-check-pointer-in-irq_domain_alloc_i.patch new file mode 100644 index 00000000000..26451ece1f2 --- /dev/null +++ b/queue-4.19/genirq-irqdomain-check-pointer-in-irq_domain_alloc_i.patch @@ -0,0 +1,66 @@ +From 74ccaeffaa18b7d5b66d5e591061208ca49dca1f Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 6 Mar 2020 18:47:20 +0100 +Subject: genirq/irqdomain: Check pointer in irq_domain_alloc_irqs_hierarchy() + +From: Alexander Sverdlin + +[ 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 +... +[] (gpiochip_hierarchy_irq_domain_alloc) +[] (__irq_domain_alloc_irqs) +[] (irq_create_fwspec_mapping) +[] (gpiochip_to_irq) +[] (gpiod_to_irq) +[] (gpio_irqs_init [gpio_irqs]) +[] (gpio_irqs_exit+0xecc/0xe84 [gpio_irqs]) +Code: bad PC value + +Signed-off-by: Alexander Sverdlin +Signed-off-by: Thomas Gleixner +Link: https://lkml.kernel.org/r/20200306174720.82604-1-alexander.sverdlin@nokia.com +Signed-off-by: Sasha Levin +--- + 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 e0eda2bd39753..0a76c44eb6b29 100644 +--- a/kernel/irq/irqdomain.c ++++ b/kernel/irq/irqdomain.c +@@ -1255,6 +1255,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); + } + +@@ -1292,11 +1297,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-4.19/gfs2-don-t-demote-a-glock-until-its-revokes-are-writ.patch b/queue-4.19/gfs2-don-t-demote-a-glock-until-its-revokes-are-writ.patch new file mode 100644 index 00000000000..141a7413efb --- /dev/null +++ b/queue-4.19/gfs2-don-t-demote-a-glock-until-its-revokes-are-writ.patch @@ -0,0 +1,46 @@ +From 007b868dd2412818578bb011cc9c18974048d8e5 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 13 Nov 2019 14:08:45 -0600 +Subject: gfs2: Don't demote a glock until its revokes are written + +From: Bob Peterson + +[ 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 +Reviewed-by: Andreas Gruenbacher +Signed-off-by: Sasha Levin +--- + fs/gfs2/glock.c | 3 +++ + 1 file changed, 3 insertions(+) + +diff --git a/fs/gfs2/glock.c b/fs/gfs2/glock.c +index ccdd8c821abd7..f8a5eef3d014b 100644 +--- a/fs/gfs2/glock.c ++++ b/fs/gfs2/glock.c +@@ -636,6 +636,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-4.19/hinic-fix-a-bug-of-waitting-for-io-stopped.patch b/queue-4.19/hinic-fix-a-bug-of-waitting-for-io-stopped.patch new file mode 100644 index 00000000000..a6892917fc1 --- /dev/null +++ b/queue-4.19/hinic-fix-a-bug-of-waitting-for-io-stopped.patch @@ -0,0 +1,92 @@ +From eff0e489f3828a10357a6b2d9aeeb707b6009266 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 20 Mar 2020 23:13:16 +0000 +Subject: hinic: fix a bug of waitting for IO stopped + +From: Luo bin + +[ 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 +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + .../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 9deec13d98e93..4c91c8ceac5f9 100644 +--- a/drivers/net/ethernet/huawei/hinic/hinic_hw_dev.c ++++ b/drivers/net/ethernet/huawei/hinic/hinic_hw_dev.c +@@ -370,50 +370,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 +@@ -433,11 +389,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-4.19/hinic-fix-wrong-para-of-wait_for_completion_timeout.patch b/queue-4.19/hinic-fix-wrong-para-of-wait_for_completion_timeout.patch new file mode 100644 index 00000000000..59f856cf4fd --- /dev/null +++ b/queue-4.19/hinic-fix-wrong-para-of-wait_for_completion_timeout.patch @@ -0,0 +1,60 @@ +From 72f9a71fa173f53462a997a63063b5447332ce03 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 20 Mar 2020 23:13:19 +0000 +Subject: hinic: fix wrong para of wait_for_completion_timeout + +From: Luo bin + +[ Upstream commit 0da7c322f116210ebfdda59c7da663a6fc5e9cc8 ] + +the second input parameter of wait_for_completion_timeout should +be jiffies instead of millisecond + +Signed-off-by: Luo bin +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + 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 4d09ea786b35f..ee715bf785adf 100644 +--- a/drivers/net/ethernet/huawei/hinic/hinic_hw_cmdq.c ++++ b/drivers/net/ethernet/huawei/hinic/hinic_hw_cmdq.c +@@ -398,7 +398,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 278dc13f3dae8..9fcf2e5e00039 100644 +--- a/drivers/net/ethernet/huawei/hinic/hinic_hw_mgmt.c ++++ b/drivers/net/ethernet/huawei/hinic/hinic_hw_mgmt.c +@@ -52,7 +52,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) +@@ -276,7 +276,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-4.19/i2c-st-fix-missing-struct-parameter-description.patch b/queue-4.19/i2c-st-fix-missing-struct-parameter-description.patch new file mode 100644 index 00000000000..92a5eed6125 --- /dev/null +++ b/queue-4.19/i2c-st-fix-missing-struct-parameter-description.patch @@ -0,0 +1,35 @@ +From 2f285c86422e9c142a62ccee72a26fcd3ff5a17e Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 26 Mar 2020 22:22:43 +0100 +Subject: i2c: st: fix missing struct parameter description + +From: Alain Volmat + +[ Upstream commit f491c6687332920e296d0209e366fe2ca7eab1c6 ] + +Fix a missing struct parameter description to allow +warning free W=1 compilation. + +Signed-off-by: Alain Volmat +Reviewed-by: Patrice Chotard +Signed-off-by: Wolfram Sang +Signed-off-by: Sasha Levin +--- + 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 9e62f893958aa..81158ae8bfe36 100644 +--- a/drivers/i2c/busses/i2c-st.c ++++ b/drivers/i2c/busses/i2c-st.c +@@ -437,6 +437,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-4.19/irqchip-gic-v4-provide-irq_retrigger-to-avoid-circul.patch b/queue-4.19/irqchip-gic-v4-provide-irq_retrigger-to-avoid-circul.patch new file mode 100644 index 00000000000..bda4ae235dc --- /dev/null +++ b/queue-4.19/irqchip-gic-v4-provide-irq_retrigger-to-avoid-circul.patch @@ -0,0 +1,146 @@ +From d530346e69f2b633013c3090984747f1552183fb Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 10 Mar 2020 18:49:21 +0000 +Subject: irqchip/gic-v4: Provide irq_retrigger to avoid circular locking + dependency + +From: Marc Zyngier + +[ 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 +Link: https://lore.kernel.org/r/20200310184921.23552-5-maz@kernel.org +Signed-off-by: Sasha Levin +--- + 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 f9b73336a39ee..fe7d63cdfb1d7 100644 +--- a/drivers/irqchip/irq-gic-v3-its.c ++++ b/drivers/irqchip/irq-gic-v3-its.c +@@ -2858,12 +2858,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-4.19/irqchip-versatile-fpga-handle-chained-irqs-properly.patch b/queue-4.19/irqchip-versatile-fpga-handle-chained-irqs-properly.patch new file mode 100644 index 00000000000..af502dff6fb --- /dev/null +++ b/queue-4.19/irqchip-versatile-fpga-handle-chained-irqs-properly.patch @@ -0,0 +1,69 @@ +From 1c48e383d03c4070bcefcbbbfc73ea0df610fd19 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 19 Mar 2020 11:34:48 +0900 +Subject: irqchip/versatile-fpga: Handle chained IRQs properly + +From: Sungbo Eo + +[ 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 +Signed-off-by: Marc Zyngier +Link: https://lore.kernel.org/r/20200319023448.1479701-1-mans0n@gorani.run +Signed-off-by: Sasha Levin +--- + 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 + #include + #include ++#include + #include + #include + #include +@@ -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-4.19/libata-remove-extra-scsi_host_put-in-ata_scsi_add_ho.patch b/queue-4.19/libata-remove-extra-scsi_host_put-in-ata_scsi_add_ho.patch new file mode 100644 index 00000000000..144088af079 --- /dev/null +++ b/queue-4.19/libata-remove-extra-scsi_host_put-in-ata_scsi_add_ho.patch @@ -0,0 +1,158 @@ +From 845d17697cf56c9c3727b802f60165843985951e Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 28 Feb 2020 19:33:35 +0800 +Subject: libata: Remove extra scsi_host_put() in ata_scsi_add_hosts() + +From: John Garry + +[ 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 +Signed-off-by: Jens Axboe +Signed-off-by: Sasha Levin +--- + 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 3a64fa4aaf7e3..0c1572a1cc5ed 100644 +--- a/drivers/ata/libata-scsi.c ++++ b/drivers/ata/libata-scsi.c +@@ -4570,22 +4570,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-4.19/locking-lockdep-avoid-recursion-in-lockdep_count_-fo.patch b/queue-4.19/locking-lockdep-avoid-recursion-in-lockdep_count_-fo.patch new file mode 100644 index 00000000000..384c17f730a --- /dev/null +++ b/queue-4.19/locking-lockdep-avoid-recursion-in-lockdep_count_-fo.patch @@ -0,0 +1,80 @@ +From f2f93e1694a80ebfe563ffea437a6063f929b00c Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 12 Mar 2020 23:12:55 +0800 +Subject: locking/lockdep: Avoid recursion in + lockdep_count_{for,back}ward_deps() + +From: Boqun Feng + +[ 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 +Signed-off-by: Boqun Feng +Signed-off-by: Peter Zijlstra (Intel) +Link: https://lkml.kernel.org/r/20200312151258.128036-1-boqun.feng@gmail.com +Signed-off-by: Sasha Levin +--- + kernel/locking/lockdep.c | 4 ++++ + 1 file changed, 4 insertions(+) + +diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c +index 1e272f6a01e73..8a1758b094b70 100644 +--- a/kernel/locking/lockdep.c ++++ b/kernel/locking/lockdep.c +@@ -1260,9 +1260,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; +@@ -1287,9 +1289,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-4.19/md-check-arrays-is-suspended-in-mddev_detach-before-.patch b/queue-4.19/md-check-arrays-is-suspended-in-mddev_detach-before-.patch new file mode 100644 index 00000000000..3efea5ae365 --- /dev/null +++ b/queue-4.19/md-check-arrays-is-suspended-in-mddev_detach-before-.patch @@ -0,0 +1,66 @@ +From 2cec749361c2b87a487fa7f907547eb1beaafc55 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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 + +[ 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 +Signed-off-by: Song Liu +Signed-off-by: Sasha Levin +--- + 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 62f214d43e15a..9426976e0860d 100644 +--- a/drivers/md/md.c ++++ b/drivers/md/md.c +@@ -5874,7 +5874,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-4.19/media-i2c-ov5695-fix-power-on-and-off-sequences.patch b/queue-4.19/media-i2c-ov5695-fix-power-on-and-off-sequences.patch new file mode 100644 index 00000000000..7b406e09c1e --- /dev/null +++ b/queue-4.19/media-i2c-ov5695-fix-power-on-and-off-sequences.patch @@ -0,0 +1,134 @@ +From 0f51566120ffe2058f422fb19ee3432aee6849b2 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 11 Mar 2020 11:47:28 +0100 +Subject: media: i2c: ov5695: Fix power on and off sequences + +From: Dongchun Zhu + +[ 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 +Signed-off-by: Tomasz Figa +Signed-off-by: Sakari Ailus +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Sasha Levin +--- + 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 5d107c53364d6..be242bb8fefcd 100644 +--- a/drivers/media/i2c/ov5695.c ++++ b/drivers/media/i2c/ov5695.c +@@ -974,16 +974,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); +@@ -994,21 +987,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; +@@ -1016,9 +1016,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) +@@ -1288,7 +1301,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-4.19/media-i2c-video-i2c-fix-build-errors-due-to-imply-hw.patch b/queue-4.19/media-i2c-video-i2c-fix-build-errors-due-to-imply-hw.patch new file mode 100644 index 00000000000..8e071378313 --- /dev/null +++ b/queue-4.19/media-i2c-video-i2c-fix-build-errors-due-to-imply-hw.patch @@ -0,0 +1,43 @@ +From 8f76537fd43543eb9fa36695419f4a7888e72376 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 24 Mar 2020 02:07:41 +0100 +Subject: media: i2c: video-i2c: fix build errors due to 'imply hwmon' + +From: Matt Ranostay + +[ 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 +Signed-off-by: Hans Verkuil +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Sasha Levin +--- + 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 f27d294dcbef5..dd50acc085d89 100644 +--- a/drivers/media/i2c/video-i2c.c ++++ b/drivers/media/i2c/video-i2c.c +@@ -105,7 +105,7 @@ static int amg88xx_xfer(struct video_i2c_data *data, char *buf) + return (ret == 2) ? 0 : -EIO; + } + +-#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-4.19/media-venus-hfi_parser-ignore-hevc-encoding-for-v1.patch b/queue-4.19/media-venus-hfi_parser-ignore-hevc-encoding-for-v1.patch new file mode 100644 index 00000000000..c3484d0546f --- /dev/null +++ b/queue-4.19/media-venus-hfi_parser-ignore-hevc-encoding-for-v1.patch @@ -0,0 +1,40 @@ +From 5a6443453df1e223338253bc3de19eb5c1d878aa Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 9 Dec 2019 20:16:52 +0100 +Subject: media: venus: hfi_parser: Ignore HEVC encoding for V1 + +From: Stephan Gerhold + +[ 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 +Signed-off-by: Stanimir Varbanov +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Sasha Levin +--- + 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-4.19/net-vxge-fix-wrong-__va_args__-usage.patch b/queue-4.19/net-vxge-fix-wrong-__va_args__-usage.patch new file mode 100644 index 00000000000..c99680cb721 --- /dev/null +++ b/queue-4.19/net-vxge-fix-wrong-__va_args__-usage.patch @@ -0,0 +1,98 @@ +From 5ea2c1e7733edaa9aa40c1c370cf07701d95a3a8 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 16 Mar 2020 22:23:47 +0800 +Subject: net: vxge: fix wrong __VA_ARGS__ usage + +From: Zheng Wei + +[ 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 +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + 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 d743a37a3cee8..e5dda2c27f187 100644 +--- a/drivers/net/ethernet/neterion/vxge/vxge-config.h ++++ b/drivers/net/ethernet/neterion/vxge/vxge-config.h +@@ -2065,7 +2065,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-4.19/null_blk-fix-spurious-io-errors-after-failed-past-wp.patch b/queue-4.19/null_blk-fix-spurious-io-errors-after-failed-past-wp.patch new file mode 100644 index 00000000000..fa3131810b8 --- /dev/null +++ b/queue-4.19/null_blk-fix-spurious-io-errors-after-failed-past-wp.patch @@ -0,0 +1,55 @@ +From dd558b891da93025e666543a2833bb95c10adf38 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 12 Feb 2020 23:23:20 +0300 +Subject: null_blk: fix spurious IO errors after failed past-wp access + +From: Alexey Dobriyan + +[ 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 +Signed-off-by: Alexey Dobriyan (SK hynix) +Signed-off-by: Jens Axboe +Signed-off-by: Sasha Levin +--- + 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 78355a0e61db6..d2d7dc9cd58d2 100644 +--- a/drivers/block/null_blk_main.c ++++ b/drivers/block/null_blk_main.c +@@ -571,6 +571,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, +@@ -1433,6 +1434,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-4.19/null_blk-fix-the-null_add_dev-error-path.patch b/queue-4.19/null_blk-fix-the-null_add_dev-error-path.patch new file mode 100644 index 00000000000..de65b9edfa8 --- /dev/null +++ b/queue-4.19/null_blk-fix-the-null_add_dev-error-path.patch @@ -0,0 +1,97 @@ +From dffee3dcdd90fea9445b64267805387f7b319069 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 9 Mar 2020 21:26:21 -0700 +Subject: null_blk: Fix the null_add_dev() error path + +From: Bart Van Assche + +[ 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 +Reviewed-by: Chaitanya Kulkarni +Cc: Johannes Thumshirn +Cc: Hannes Reinecke +Cc: Ming Lei +Cc: Christoph Hellwig +Signed-off-by: Jens Axboe +Signed-off-by: Sasha Levin +--- + 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 c5c0b7c894815..002072429290e 100644 +--- a/drivers/block/null_blk_main.c ++++ b/drivers/block/null_blk_main.c +@@ -1844,6 +1844,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-4.19/null_blk-handle-null_add_dev-failures-properly.patch b/queue-4.19/null_blk-handle-null_add_dev-failures-properly.patch new file mode 100644 index 00000000000..229742cf964 --- /dev/null +++ b/queue-4.19/null_blk-handle-null_add_dev-failures-properly.patch @@ -0,0 +1,64 @@ +From 492fcd7088035adbe2d65fab44f90d8749c45917 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 9 Mar 2020 21:26:22 -0700 +Subject: null_blk: Handle null_add_dev() failures properly + +From: Bart Van Assche + +[ 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 +Reviewed-by: Chaitanya Kulkarni +Cc: Johannes Thumshirn +Cc: Hannes Reinecke +Cc: Ming Lei +Cc: Christoph Hellwig +Signed-off-by: Jens Axboe +Signed-off-by: Sasha Levin +--- + 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 002072429290e..78355a0e61db6 100644 +--- a/drivers/block/null_blk_main.c ++++ b/drivers/block/null_blk_main.c +@@ -1480,7 +1480,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-4.19/pci-switchtec-fix-init_completion-race-condition-wit.patch b/queue-4.19/pci-switchtec-fix-init_completion-race-condition-wit.patch new file mode 100644 index 00000000000..0cd14934994 --- /dev/null +++ b/queue-4.19/pci-switchtec-fix-init_completion-race-condition-wit.patch @@ -0,0 +1,52 @@ +From 81f8975e669e5c196b71d4f119e0fc235bf5e777 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sat, 21 Mar 2020 12:25:45 +0100 +Subject: PCI/switchtec: Fix init_completion race condition with poll_wait() + +From: Logan Gunthorpe + +[ 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 +Signed-off-by: Logan Gunthorpe +Signed-off-by: Thomas Gleixner +Signed-off-by: Peter Zijlstra (Intel) +Acked-by: Bjorn Helgaas +Link: https://lkml.kernel.org/r/20200313183608.2646-1-logang@deltatee.com +Signed-off-by: Sasha Levin +--- + 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 43431816412c1..291c0074ad6f4 100644 +--- a/drivers/pci/switch/switchtec.c ++++ b/drivers/pci/switch/switchtec.c +@@ -147,7 +147,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-4.19/pstore-platform-fix-potential-mem-leak-if-pstore_ini.patch b/queue-4.19/pstore-platform-fix-potential-mem-leak-if-pstore_ini.patch new file mode 100644 index 00000000000..fdcd083f45a --- /dev/null +++ b/queue-4.19/pstore-platform-fix-potential-mem-leak-if-pstore_ini.patch @@ -0,0 +1,41 @@ +From 7b1eacb98b2adbdc0397a5852ea81c06a7104fb1 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 7 Feb 2020 17:46:39 +0800 +Subject: pstore/platform: fix potential mem leak if pstore_init_fs failed + +From: chenqiwu + +[ 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 +Link: https://lore.kernel.org/r/1581068800-13817-1-git-send-email-qiwuchen55@gmail.com +Signed-off-by: Kees Cook +Signed-off-by: Sasha Levin +--- + 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 4bae3f4fe829d..dcd9c3163587c 100644 +--- a/fs/pstore/platform.c ++++ b/fs/pstore/platform.c +@@ -802,9 +802,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-4.19/qlcnic-fix-bad-kzalloc-null-test.patch b/queue-4.19/qlcnic-fix-bad-kzalloc-null-test.patch new file mode 100644 index 00000000000..c785ba88c4d --- /dev/null +++ b/queue-4.19/qlcnic-fix-bad-kzalloc-null-test.patch @@ -0,0 +1,35 @@ +From 9e36bf207ee788166201b2afa098029ef8f3be6e Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 26 Mar 2020 18:14:29 +0800 +Subject: qlcnic: Fix bad kzalloc null test + +From: Xu Wang + +[ 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 +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + 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-4.19/rxrpc-abstract-out-the-calculation-of-whether-there-.patch b/queue-4.19/rxrpc-abstract-out-the-calculation-of-whether-there-.patch new file mode 100644 index 00000000000..735bb870ad7 --- /dev/null +++ b/queue-4.19/rxrpc-abstract-out-the-calculation-of-whether-there-.patch @@ -0,0 +1,80 @@ +From 23dac5828879ceab834e9b8edaa8b265be03a7bc Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 13 Mar 2020 09:05:38 +0000 +Subject: rxrpc: Abstract out the calculation of whether there's Tx space + +From: David Howells + +[ 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 +Signed-off-by: Sasha Levin +--- + 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 250d3dae8af4d..7ee72053037a3 100644 +--- a/net/rxrpc/sendmsg.c ++++ b/net/rxrpc/sendmsg.c +@@ -21,6 +21,21 @@ + #include + #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. + */ +@@ -30,9 +45,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) +@@ -72,9 +85,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) +@@ -305,9 +316,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-4.19/sched-avoid-scale-real-weight-down-to-zero.patch b/queue-4.19/sched-avoid-scale-real-weight-down-to-zero.patch new file mode 100644 index 00000000000..f2c1437727b --- /dev/null +++ b/queue-4.19/sched-avoid-scale-real-weight-down-to-zero.patch @@ -0,0 +1,82 @@ +From df31dc9ed27c30a689c387dcb5ca5f54cf02b76e Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 18 Mar 2020 10:15:15 +0800 +Subject: sched: Avoid scale real weight down to zero + +From: Michael Wang + +[ 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 +Signed-off-by: Michael Wang +Signed-off-by: Peter Zijlstra (Intel) +Reviewed-by: Vincent Guittot +Link: https://lkml.kernel.org/r/38e8e212-59a1-64b2-b247-b6d0b52d8dc1@linux.alibaba.com +Signed-off-by: Sasha Levin +--- + 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 94bec97bd5e28..5f0eb4565957f 100644 +--- a/kernel/sched/sched.h ++++ b/kernel/sched/sched.h +@@ -123,7 +123,13 @@ static inline void cpu_load_update_active(struct rq *this_rq) { } + #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-4.19/selftests-x86-ptrace_syscall_32-fix-no-vdso-segfault.patch b/queue-4.19/selftests-x86-ptrace_syscall_32-fix-no-vdso-segfault.patch new file mode 100644 index 00000000000..398e2d421f0 --- /dev/null +++ b/queue-4.19/selftests-x86-ptrace_syscall_32-fix-no-vdso-segfault.patch @@ -0,0 +1,42 @@ +From 329a8e6031177aee0e8788675586098fee157a1b Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 12 Mar 2020 15:35:51 -0700 +Subject: selftests/x86/ptrace_syscall_32: Fix no-vDSO segfault + +From: Andy Lutomirski + +[ Upstream commit 630b99ab60aa972052a4202a1ff96c7e45eb0054 ] + +If AT_SYSINFO is not present, don't try to call a NULL pointer. + +Reported-by: kbuild test robot +Signed-off-by: Andy Lutomirski +Signed-off-by: Borislav Petkov +Link: https://lkml.kernel.org/r/faaf688265a7e1a5b944d6f8bc0f6368158306d3.1584052409.git.luto@kernel.org +Signed-off-by: Sasha Levin +--- + 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-4.19/series b/queue-4.19/series new file mode 100644 index 00000000000..49075c4c4ee --- /dev/null +++ b/queue-4.19/series @@ -0,0 +1,40 @@ +arm-dts-sun8i-a83t-tbs-a711-hm5065-doesn-t-like-such.patch +bus-sunxi-rsb-return-correct-data-when-mixing-16-bit.patch +rxrpc-abstract-out-the-calculation-of-whether-there-.patch +net-vxge-fix-wrong-__va_args__-usage.patch +hinic-fix-a-bug-of-waitting-for-io-stopped.patch +hinic-fix-wrong-para-of-wait_for_completion_timeout.patch +cxgb4-ptp-pass-the-sign-of-offset-delta-in-fw-cmd.patch +qlcnic-fix-bad-kzalloc-null-test.patch +i2c-st-fix-missing-struct-parameter-description.patch +cpufreq-imx6q-fixes-unwanted-cpu-overclocking-on-i.m.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 +xhci-bail-out-early-if-driver-can-t-accress-host-in-.patch +x86-don-t-let-pgprot_modify-change-the-page-encrypti.patch +block-keep-bdi-io_pages-in-sync-with-max_sectors_kb-.patch +irqchip-versatile-fpga-handle-chained-irqs-properly.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 +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-don-t-demote-a-glock-until-its-revokes-are-writ.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 +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-track-reloc-roots-based-on-their-commit-root-b.patch diff --git a/queue-4.19/usb-dwc3-core-add-support-for-disabling-ss-instances.patch b/queue-4.19/usb-dwc3-core-add-support-for-disabling-ss-instances.patch new file mode 100644 index 00000000000..a73a4cab288 --- /dev/null +++ b/queue-4.19/usb-dwc3-core-add-support-for-disabling-ss-instances.patch @@ -0,0 +1,99 @@ +From 1d314a04cf6c49af5caf612f91c813488a848874 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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 + +[ 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 +Cc: Jianxin Pan +Cc: Thinh Nguyen +Cc: Jun Li +Reported-by: Tim +Signed-off-by: Neil Armstrong +Signed-off-by: Felipe Balbi +Signed-off-by: Sasha Levin +--- + 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 6666d2a52bf56..60d08269ad9a0 100644 +--- a/drivers/usb/dwc3/core.c ++++ b/drivers/usb/dwc3/core.c +@@ -981,6 +981,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); + } + +@@ -1287,6 +1290,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 131028501752b..e34308d64619e 100644 +--- a/drivers/usb/dwc3/core.h ++++ b/drivers/usb/dwc3/core.h +@@ -242,6 +242,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) + +@@ -992,6 +993,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 +@@ -1163,6 +1166,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-4.19/x86-boot-use-unsigned-comparison-for-addresses.patch b/queue-4.19/x86-boot-use-unsigned-comparison-for-addresses.patch new file mode 100644 index 00000000000..b92177f0ee1 --- /dev/null +++ b/queue-4.19/x86-boot-use-unsigned-comparison-for-addresses.patch @@ -0,0 +1,71 @@ +From 55711619be5fc98b7e3f45e4269061cc12833a33 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sun, 8 Mar 2020 09:08:44 +0100 +Subject: x86/boot: Use unsigned comparison for addresses + +From: Arvind Sankar + +[ 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 +Signed-off-by: Ard Biesheuvel +Signed-off-by: Ingo Molnar +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 +--- + 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 37380c0d59996..01d628ea34024 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 4eaa724afce34..9fa644c62839f 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-4.19/x86-don-t-let-pgprot_modify-change-the-page-encrypti.patch b/queue-4.19/x86-don-t-let-pgprot_modify-change-the-page-encrypti.patch new file mode 100644 index 00000000000..047c0fd5b57 --- /dev/null +++ b/queue-4.19/x86-don-t-let-pgprot_modify-change-the-page-encrypti.patch @@ -0,0 +1,69 @@ +From 5574d84d621814f0d1ac343870d4da8a1fb5e276 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 4 Mar 2020 12:45:26 +0100 +Subject: x86: Don't let pgprot_modify() change the page encryption bit + +From: Thomas Hellstrom + +[ 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 +Signed-off-by: Borislav Petkov +Reviewed-by: Dave Hansen +Acked-by: Tom Lendacky +Link: https://lkml.kernel.org/r/20200304114527.3636-2-thomas_os@shipmail.org +Signed-off-by: Sasha Levin +--- + 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 690c0307afed0..2e1ed12c65f82 100644 +--- a/arch/x86/include/asm/pgtable.h ++++ b/arch/x86/include/asm/pgtable.h +@@ -608,12 +608,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 106b7d0e2dae5..71ea49e7db747 100644 +--- a/arch/x86/include/asm/pgtable_types.h ++++ b/arch/x86/include/asm/pgtable_types.h +@@ -124,7 +124,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-4.19/xhci-bail-out-early-if-driver-can-t-accress-host-in-.patch b/queue-4.19/xhci-bail-out-early-if-driver-can-t-accress-host-in-.patch new file mode 100644 index 00000000000..c4b231fe940 --- /dev/null +++ b/queue-4.19/xhci-bail-out-early-if-driver-can-t-accress-host-in-.patch @@ -0,0 +1,45 @@ +From 7cf1f7fac9e5c098c1343e606e9bd36e060f889f Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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 + +[ 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 +Link: https://lore.kernel.org/r/20200312144517.1593-2-mathias.nyman@linux.intel.com +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Sasha Levin +--- + 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 65cc362717fcb..b4177287d7d0f 100644 +--- a/drivers/usb/host/xhci.c ++++ b/drivers/usb/host/xhci.c +@@ -1147,8 +1147,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 + -- 2.47.3