summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2021-07-27KVM: SVM: delay svm_vcpu_init_msrpm after svm->vmcb is initializedPaolo Bonzini
Right now, svm_hv_vmcb_dirty_nested_enlightenments has an incorrect dereference of vmcb->control.reserved_sw before the vmcb is checked for being non-NULL. The compiler is usually sinking the dereference after the check; instead of doing this ourselves in the source, ensure that svm_hv_vmcb_dirty_nested_enlightenments is only called with a non-NULL VMCB. Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Cc: Vineeth Pillai <viremana@linux.microsoft.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> [Untested for now due to issues with my AMD machine. - Paolo]
2021-07-27KVM: selftests: Introduce access_tracking_perf_testDavid Matlack
This test measures the performance effects of KVM's access tracking. Access tracking is driven by the MMU notifiers test_young, clear_young, and clear_flush_young. These notifiers do not have a direct userspace API, however the clear_young notifier can be triggered by marking a pages as idle in /sys/kernel/mm/page_idle/bitmap. This test leverages that mechanism to enable access tracking on guest memory. To measure performance this test runs a VM with a configurable number of vCPUs that each touch every page in disjoint regions of memory. Performance is measured in the time it takes all vCPUs to finish touching their predefined region. Example invocation: $ ./access_tracking_perf_test -v 8 Testing guest mode: PA-bits:ANY, VA-bits:48, 4K pages guest physical test memory offset: 0xffdfffff000 Populating memory : 1.337752570s Writing to populated memory : 0.010177640s Reading from populated memory : 0.009548239s Mark memory idle : 23.973131748s Writing to idle memory : 0.063584496s Mark memory idle : 24.924652964s Reading from idle memory : 0.062042814s Breaking down the results: * "Populating memory": The time it takes for all vCPUs to perform the first write to every page in their region. * "Writing to populated memory" / "Reading from populated memory": The time it takes for all vCPUs to write and read to every page in their region after it has been populated. This serves as a control for the later results. * "Mark memory idle": The time it takes for every vCPU to mark every page in their region as idle through page_idle. * "Writing to idle memory" / "Reading from idle memory": The time it takes for all vCPUs to write and read to every page in their region after it has been marked idle. This test should be portable across architectures but it is only enabled for x86_64 since that's all I have tested. Reviewed-by: Ben Gardon <bgardon@google.com> Signed-off-by: David Matlack <dmatlack@google.com> Message-Id: <20210713220957.3493520-7-dmatlack@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-07-27KVM: selftests: Fix missing break in dirty_log_perf_test arg parsingDavid Matlack
There is a missing break statement which causes a fallthrough to the next statement where optarg will be null and a segmentation fault will be generated. Fixes: 9e965bb75aae ("KVM: selftests: Add backing src parameter to dirty_log_perf_test") Reviewed-by: Ben Gardon <bgardon@google.com> Signed-off-by: David Matlack <dmatlack@google.com> Message-Id: <20210713220957.3493520-6-dmatlack@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-07-27x86/kvm: fix vcpu-id indexed array sizesJuergen Gross
KVM_MAX_VCPU_ID is the maximum vcpu-id of a guest, and not the number of vcpu-ids. Fix array indexed by vcpu-id to have KVM_MAX_VCPU_ID+1 elements. Note that this is currently no real problem, as KVM_MAX_VCPU_ID is an odd number, resulting in always enough padding being available at the end of those arrays. Nevertheless this should be fixed in order to avoid rare problems in case someone is using an even number for KVM_MAX_VCPU_ID. Signed-off-by: Juergen Gross <jgross@suse.com> Message-Id: <20210701154105.23215-2-jgross@suse.com> Cc: stable@vger.kernel.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-07-27Merge branch 'for-5.14-fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq Pull workqueue fix from Tejun Heo: "Fix a use-after-free in allocation failure handling path" * 'for-5.14-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq: workqueue: fix UAF in pwq_unbound_release_workfn()
2021-07-27net: hns3: change the method of obtaining default ptp cycleYufeng Mo
The ptp cycle is related to the hardware, so it may cause compatibility issues if a fixed value is used in driver. Therefore, the method of obtaining this value is changed to read from the register rather than use a fixed value in driver. Fixes: 0bf5eb788512 ("net: hns3: add support for PTP") Signed-off-by: Yufeng Mo <moyufeng@huawei.com> Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-07-27timers: Move clearing of base::timer_running under base:: LockThomas Gleixner
syzbot reported KCSAN data races vs. timer_base::timer_running being set to NULL without holding base::lock in expire_timers(). This looks innocent and most reads are clearly not problematic, but Frederic identified an issue which is: int data = 0; void timer_func(struct timer_list *t) { data = 1; } CPU 0 CPU 1 ------------------------------ -------------------------- base = lock_timer_base(timer, &flags); raw_spin_unlock(&base->lock); if (base->running_timer != timer) call_timer_fn(timer, fn, baseclk); ret = detach_if_pending(timer, base, true); base->running_timer = NULL; raw_spin_unlock_irqrestore(&base->lock, flags); raw_spin_lock(&base->lock); x = data; If the timer has previously executed on CPU 1 and then CPU 0 can observe base->running_timer == NULL and returns, assuming the timer has completed, but it's not guaranteed on all architectures. The comment for del_timer_sync() makes that guarantee. Moving the assignment under base->lock prevents this. For non-RT kernel it's performance wise completely irrelevant whether the store happens before or after taking the lock. For an RT kernel moving the store under the lock requires an extra unlock/lock pair in the case that there is a waiter for the timer, but that's not the end of the world. Reported-by: syzbot+aa7c2385d46c5eba0b89@syzkaller.appspotmail.com Reported-by: syzbot+abea4558531bae1ba9fe@syzkaller.appspotmail.com Fixes: 030dcdd197d7 ("timers: Prepare support for PREEMPT_RT") Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Link: https://lore.kernel.org/r/87lfea7gw8.fsf@nanos.tec.linutronix.de Cc: stable@vger.kernel.org
2021-07-27torture: Make kvm-test-1-run-qemu.sh check for reboot loopsPaul E. McKenney
It turns out that certain types of early boot bugs can result in reboot loops, even within a guest OS running under qemu/KVM. This commit therefore upgrades the kvm-test-1-run-qemu.sh script's hang-detection heuristics to detect such situations and to terminate the run when they occur. Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2021-07-27torture: Add timestamps to kvm-test-1-run-qemu.sh outputPaul E. McKenney
The kvm-test-1-run-qemu.sh script logs the torture-test start time and also when it starts getting impatient for the test to finish. However, it does not timestamp these log messages, which can make debugging needlessly challenging. This commit therefore adds timestamps to these messages. Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2021-07-27torture: Don't use "test" command's "-a" argumentPaul E. McKenney
There was a time long ago when the "test" command's documentation claimed that the "-a" and "-o" arguments did something useful. But this documentation now suggests letting the shell execute these boolean operators, so this commit applies that suggestion to kvm-test-1-run-qemu.sh. Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2021-07-27torture: Make kvm-test-1-run-batch.sh select per-scenario affinity masksPaul E. McKenney
This commit causes kvm-test-1-run-batch.sh to use the new kvm-assign-cpus.sh and kvm-get-cpus-script.sh scripts to create a TORTURE_AFFINITY environment variable containing either an empty string (for no affinity) or a list of CPUs to pin the scenario's vCPUs to. The additional change to kvm-test-1-run.sh places the per-scenario number-of-CPUs information where it can easily be found. If there is some reason why affinity cannot be supplied, this commit prints and logs the reason via changes to kvm-again.sh. Finally, this commit updates the kvm-remote.sh script to copy the qemu-affinity output files back to the host system. Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2021-07-27torture: Consistently name "qemu*" test output filesPaul E. McKenney
There is "qemu-affinity", "qemu-cmd", "qemu-retval", but also "qemu_pid". This is hard to remember, not so good for bash tab completion, and just plain inconsistent. This commit therefore renames the "qemu_pid" file to "qemu-pid". A couple of the scripts must deal with old runs, and thus must handle both "qemu_pid" and "qemu-pid", but new runs will produce "qemu-pid". Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2021-07-27torture: Use numeric taskset argument in jitter.shPaul E. McKenney
The jitter.sh script has some entertaining awk code to generate a hex mask from a randomly selected CPU number, which is handed to the "taskset" command. Except that this command has a "-c" parameter to take a comma/dash-separated list of CPU numbers. This commit therefore saves a few lines of awk by switching to a single-number CPU list. Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2021-07-27rcutorture: Upgrade two-CPU scenarios to four CPUsPaul E. McKenney
There is no way to place the vCPUs in a two-CPU rcutorture scenario to get variable memory latency. This commit therefore upgrades the current two-CPU rcutorture scenarios to four CPUs. Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2021-07-27torture: Make kvm-test-1-run-qemu.sh apply affinityPaul E. McKenney
This commit causes the kvm-test-1-run-qemu.sh script to check the TORTURE_AFFINITY environment variable and to add "taskset" commands to the qemu-cmd file. The first "taskset" command is applied only if the TORTURE_AFFINITY environment variable is a non-empty string, and this command pins the current scenario's guest OS to the specified CPUs. The second "taskset" command reports the guest OS's affinity in a new "qemu-affinity" file. Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2021-07-27torture: Don't redirect qemu-cmd comment linesPaul E. McKenney
Currently, kvm-test-1-run-qemu.sh applies redirection to each and every line of each qemu-cmd script. Only the first line (the only one that is not a bash comment) needs to be redirected. Although redirecting the comments is currently harmless, just adding to the comment, it is an accident waiting to happen. This commit therefore adjusts the "sed" command to redirect only the qemu-system* command itself. Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2021-07-27torture: Make kvm.sh select per-scenario affinity masksPaul E. McKenney
This commit causes kvm.sh to use the new kvm-assign-cpus.sh and kvm-get-cpus-script.sh scripts to create a TORTURE_AFFINITY environment variable containing either an empty string (for no affinity) or a list of CPUs to pin the scenario's vCPUs to. A later commit will make use of this information to actually pin the vCPUs. Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2021-07-27scftorture: Avoid NULL pointer exception on early exitPaul E. McKenney
When scftorture finds an error in the module parameters controlling the relative frequencies of smp_call_function*() variants, it takes an early exit. So early that it has not allocated memory to track the kthreads running the test, which results in a segfault. This commit therefore checks for the existence of the memory before attempting to stop the kthreads that would otherwise have been recorded in that non-existent memory. Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2021-07-27scftorture: Add RPC-like IPI testsPaul E. McKenney
This commit adds the single_weight_rpc module parameter, which causes the IPI handler to awaken the IPI sender. In many scheduler configurations, this will result in an IPI back to the sender that is likely to be received at a time when the sender CPU is idle. The intent is to stress IPI reception during CPU busy-to-idle transitions. Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2021-07-27locktorture: Count lock readersPaul E. McKenney
Currently, the lock_is_read_held variable is bool, so that a reader sets it to true just after lock acquisition and then to false just before lock release. This works in a rough statistical sense, but can result in false negatives just after one of a pair of concurrent readers has released the lock. This approach does have low overhead, but at the expense of the setting to true potentially never leaving the reader's store buffer, thus resulting in an unconditional false negative. This commit therefore converts this variable to atomic_t and makes the reader use atomic_inc() just after acquisition and atomic_dec() just before release. This does increase overhead, but this increase is negligible compared to the 10-microsecond lock hold time. Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2021-07-27locktorture: Mark statistics data racesPaul E. McKenney
The lock_stress_stats structure's ->n_lock_fail and ->n_lock_acquired fields are incremented and sampled locklessly using plain C-language statements, which KCSAN objects to. This commit therefore marks the statistics gathering with data_race() to flag the intent. While in the area, this commit also reduces the number of accesses to the ->n_lock_acquired field, thus eliminating some possible check/use confusion. Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2021-07-27rcuscale: Console output claims too few grace periodsJiangong.Han
The rcuscale console output claims N grace periods, numbered from zero to N, which means that there were really N+1 grace periods. The root cause of this bug is that rcu_scale_writer() stores the number of the last grace period (numbered from zero) into writer_n_durations[me] instead of the number of grace periods. This commit therefore assigns the actual number of grace periods to writer_n_durations[me], and also makes the corresponding adjustment to the loop outputting per-grace-period measurements. Sample of old console output: rcu-scale: writer 0 gps: 133 ...... rcu-scale: 0 writer-duration: 0 44003961 rcu-scale: 0 writer-duration: 1 32003582 ...... rcu-scale: 0 writer-duration: 132 28004391 rcu-scale: 0 writer-duration: 133 27996410 Sample of new console output: rcu-scale: writer 0 gps: 134 ...... rcu-scale: 0 writer-duration: 0 44003961 rcu-scale: 0 writer-duration: 1 32003582 ...... rcu-scale: 0 writer-duration: 132 28004391 rcu-scale: 0 writer-duration: 133 27996410 Signed-off-by: Jiangong.Han <jiangong.han@windriver.com> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2021-07-27rcutorture: Preempt rather than block when testing task stallsPaul E. McKenney
Currently, rcu_torture_stall() does a one-jiffy timed wait when stall_cpu_block is set. This works, but emits a pointless splat in CONFIG_PREEMPT=y kernels. This commit avoids this splat by instead invoking preempt_schedule() in CONFIG_PREEMPT=y kernels. This uses an admittedly ugly #ifdef, but abstracted approaches just looked worse. A prettier approach would provide a preempt_schedule() definition with a WARN_ON() for CONFIG_PREEMPT=n kernels, but this seems quite silly. Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2021-07-27refscale: Add measurement of clock readoutPaul E. McKenney
This commit adds a "clock" type to refscale, which checks the performance of ktime_get_real_fast_ns(). Use the "clocksource=" kernel boot parameter to select the underlying clock source. [ paulmck: Work around compiler false positive per kernel test robot. ] Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2021-07-27clk: qcom: smd-rpm: Fix MSM8936 RPM_SMD_PCNOC_A_CLKShawn Guo
Commit a0384ecfe2aa ("clk: qcom: smd-rpm: De-duplicate identical entries") introduces the following regression on MSM8936/MSM8939, as RPM_SMD_PCNOC_A_CLK gets pointed to pcnoc_clk by mistake. Fix it by correcting the clock to pcnoc_a_clk. [ 1.307363] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 1.313593] Mem abort info: [ 1.322512] ESR = 0x96000004 [ 1.325132] EC = 0x25: DABT (current EL), IL = 32 bits [ 1.338872] SET = 0, FnV = 0 [ 1.355483] EA = 0, S1PTW = 0 [ 1.368702] FSC = 0x04: level 0 translation fault [ 1.383294] Data abort info: [ 1.398292] ISV = 0, ISS = 0x00000004 [ 1.398297] CM = 0, WnR = 0 [ 1.398301] [0000000000000000] user address but active_mm is swapper [ 1.404193] Internal error: Oops: 96000004 [#1] PREEMPT SMP [ 1.420596] Modules linked in: [ 1.420604] CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 5.14.0-rc3+ #198 [ 1.441010] pc : __clk_register+0x48/0x780 [ 1.446045] lr : __clk_register+0x3c/0x780 [ 1.449953] sp : ffff800010063440 [ 1.454031] x29: ffff800010063440 x28: 0000000000000004 x27: 0000000000000066 [ 1.457423] x26: 0000000000000001 x25: 000000007fffffff x24: ffff800010f9f388 [ 1.464540] x23: ffff00007fc12a90 x22: ffff0000034b2010 x21: 0000000000000000 [ 1.471658] x20: ffff800010f9fff8 x19: ffff00000152a700 x18: 0000000000000001 [ 1.478778] x17: ffff00007fbd40c8 x16: 0000000000000460 x15: 0000000000000465 [ 1.485895] x14: ffffffffffffffff x13: 746e756f635f7265 x12: 696669746f6e5f6b [ 1.493013] x11: 0000000000000006 x10: 0000000000000000 x9 : 0000000000000000 [ 1.500131] x8 : ffff00000152a800 x7 : 0000000000000000 x6 : 000000000000003f [ 1.507249] x5 : 0000000000000040 x4 : 0000000000000000 x3 : 0000000000000004 [ 1.514367] x2 : 0000000000000000 x1 : 0000000000000cc0 x0 : ffff00000152a700 [ 1.521486] Call trace: [ 1.528598] __clk_register+0x48/0x780 [ 1.530855] clk_hw_register+0x20/0x60 [ 1.534674] devm_clk_hw_register+0x50/0xa8 [ 1.538408] rpm_smd_clk_probe+0x1a4/0x260 [ 1.542488] platform_probe+0x68/0xd8 [ 1.546653] really_probe+0x140/0x2f8 [ 1.550386] __driver_probe_device+0x78/0xe0 [ 1.554033] driver_probe_device+0x80/0x110 [ 1.558373] __device_attach_driver+0x90/0xe0 [ 1.562280] bus_for_each_drv+0x78/0xc8 [ 1.566793] __device_attach+0xf0/0x150 [ 1.570438] device_initial_probe+0x14/0x20 [ 1.574259] bus_probe_device+0x9c/0xa8 [ 1.578425] device_add+0x378/0x870 [ 1.582243] of_device_add+0x44/0x60 [ 1.585716] of_platform_device_create_pdata+0xc0/0x110 [ 1.589538] of_platform_bus_create+0x17c/0x388 [ 1.594485] of_platform_populate+0x50/0xf0 [ 1.598998] qcom_smd_rpm_probe+0xd4/0x128 [ 1.603164] rpmsg_dev_probe+0xbc/0x1a8 [ 1.607330] really_probe+0x140/0x2f8 [ 1.611063] __driver_probe_device+0x78/0xe0 [ 1.614883] driver_probe_device+0x80/0x110 [ 1.619224] __device_attach_driver+0x90/0xe0 [ 1.623131] bus_for_each_drv+0x78/0xc8 [ 1.627643] __device_attach+0xf0/0x150 [ 1.631289] device_initial_probe+0x14/0x20 [ 1.635109] bus_probe_device+0x9c/0xa8 [ 1.639275] device_add+0x378/0x870 [ 1.643095] device_register+0x20/0x30 [ 1.646567] rpmsg_register_device+0x54/0x90 [ 1.650387] qcom_channel_state_worker+0x168/0x288 [ 1.654814] process_one_work+0x1a0/0x328 [ 1.659415] worker_thread+0x4c/0x420 [ 1.663494] kthread+0x150/0x160 [ 1.667138] ret_from_fork+0x10/0x18 [ 1.670442] Code: 97f56b92 b40034a0 aa0003f3 52819801 (f94002a0) [ 1.674004] ---[ end trace 412fa6f47384cdfe ]--- Fixes: a0384ecfe2aa ("clk: qcom: smd-rpm: De-duplicate identical entries") Signed-off-by: Shawn Guo <shawn.guo@linaro.org> Link: https://lore.kernel.org/r/20210727092613.23056-1-shawn.guo@linaro.org Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2021-07-27fpga: dfl: fme: Fix cpu hotplug issue in performance reportingKajol Jain
The performance reporting driver added cpu hotplug feature but it didn't add pmu migration call in cpu offline function. This can create an issue incase the current designated cpu being used to collect fme pmu data got offline, as based on current code we are not migrating fme pmu to new target cpu. Because of that perf will still try to fetch data from that offline cpu and hence we will not get counter data. Patch fixed this issue by adding pmu_migrate_context call in fme_perf_offline_cpu function. Fixes: 724142f8c42a ("fpga: dfl: fme: add performance reporting support") Cc: stable@vger.kernel.org Tested-by: Xu Yilun <yilun.xu@intel.com> Acked-by: Wu Hao <hao.wu@intel.com> Signed-off-by: Kajol Jain <kjain@linux.ibm.com> Signed-off-by: Moritz Fischer <mdf@kernel.org>
2021-07-27io_uring: always reissue from task_work contextJens Axboe
As a safeguard, if we're going to queue async work, do it from task_work from the original task. This ensures that we can always sanely create threads, regards of what the reissue context may be. Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-07-27maintainers: add bugs and chat URLs for amdgpuSimon Ser
Add links to the issue tracker and the IRC channel for the amdgpu driver. Signed-off-by: Simon Ser <contact@emersion.fr> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Pan Xinhui <Xinhui.Pan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-07-27drm/amdgpu/display: only enable aux backlight control for OLED panelsAlex Deucher
We've gotten a number of reports about backlight control not working on panels which indicate that they use aux backlight control. A recent patch: commit 2d73eabe2984a435737498ab39bb1500a9ffe9a9 Author: Camille Cho <Camille.Cho@amd.com> Date: Thu Jul 8 18:28:37 2021 +0800 drm/amd/display: Only set default brightness for OLED [Why] We used to unconditionally set backlight path as AUX for panels capable of backlight adjustment via DPCD in set default brightness. [How] This should be limited to OLED panel only since we control backlight via PWM path for SDR mode in LCD HDR panel. Reviewed-by: Krunoslav Kovac <krunoslav.kovac@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Camille Cho <Camille.Cho@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Changes some other code to only use aux for backlight control on OLED panels. The commit message seems to indicate that PWM should be used for SDR mode on HDR panels. Do something similar for backlight control in general. This may need to be revisited if and when HDR started to get used. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1438 Bug: https://bugzilla.kernel.org/show_bug.cgi?id=213715 Reviewed-by: Roman Li <Roman.Li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-07-27drm/amd/display: ensure dentist display clock update finished in DCN20Dale Zhao
[Why] We don't check DENTIST_DISPCLK_CHG_DONE to ensure dentist display clockis updated to target value. In some scenarios with large display clock margin, it will deliver unfinished display clock and cause issues like display black screen. [How] Checking DENTIST_DISPCLK_CHG_DONE to ensure display clock has been update to target value before driver do other clock related actions. Reviewed-by: Cyr Aric <aric.cyr@amd.com> Acked-by: Solomon Chiu <solomon.chiu@amd.com> Signed-off-by: Dale Zhao <dale.zhao@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2021-07-27drm/amd/display: Add missing DCN21 IP parameterVictor Lu
[why] IP parameter min_meta_chunk_size_bytes is read for bandwidth calculations but it was never defined. [how] Define min_meta_chunk_size_bytes and initialize value to 256. Reviewed-by: Laktyushkin Dmytro <dmytro.laktyushkin@amd.com> Acked-by: Solomon Chiu <solomon.chiu@amd.com> Signed-off-by: Victor Lu <victorchengchi.lu@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-07-27drm/amd/display: Guard DST_Y_PREFETCH register overflow in DCN21Victor Lu
[why] DST_Y_PREFETCH can overflow when DestinationLinesForPrefetch values are too large due to the former being limited to 8 bits. [how] Set the maximum value of DestinationLinesForPrefetch to be 255 * refclk period. Reviewed-by: Laktyushkin Dmytro <dmytro.laktyushkin@amd.com> Acked-by: Solomon Chiu <solomon.chiu@amd.com> Signed-off-by: Victor Lu <victorchengchi.lu@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-07-27drm/amdgpu: Check pmops for desired suspend statePratik Vishwakarma
[Why] User might change the suspend behaviour from OS. [How] Check with pm for target suspend state and set s0ix flag only for s2idle state. v2: User might change default suspend state, use target state v3: squash in build fix Suggested-by: Lijo Lazar <Lijo.Lazar@amd.com> Signed-off-by: Pratik Vishwakarma <Pratik.Vishwakarma@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2021-07-27perf pmu: Fix alias matchingJohn Garry
Commit c47a5599eda324ba ("perf tools: Fix pattern matching for same substring in different PMU type"), may have fixed some alias matching, but has broken some others. Firstly it cannot handle the simple scenario of PMU name in form pmu_name{digits} - it can only handle pmu_name_{digits}. Secondly it cannot handle more complex matching in the case where we have multiple tokens. In this scenario, the code failed to realise that we may examine multiple substrings in the PMU name. Fix in two ways: - Change perf_pmu__valid_suffix() to accept a PMU name without '_' in the suffix - Only pay attention to perf_pmu__valid_suffix() for the final token Also add const qualifiers as necessary to avoid casting. Fixes: c47a5599eda324ba ("perf tools: Fix pattern matching for same substring in different PMU type") Signed-off-by: John Garry <john.garry@huawei.com> Tested-by: Jin Yao <yao.jin@linux.intel.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Ian Rogers <irogers@google.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Kajol Jain <kjain@linux.ibm.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lore.kernel.org/lkml/1626793819-79090-1-git-send-email-john.garry@huawei.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2021-07-27Revert "thunderbolt: Hide authorized attribute if router does not support ↵Mika Westerberg
PCIe tunnels" This reverts commit 6f3badead6a078cf3c71f381f9d84ac922984a00. It turns out bolt depends on having authorized attribute visible under each device. Hiding it makes bolt crash as several people have reported on various bug trackers. For this reason revert the commit. Link: https://gitlab.freedesktop.org/bolt/bolt/-/issues/174 Link: https://bugzilla.redhat.com/show_bug.cgi?id=1979765 Link: https://bugs.archlinux.org/task/71569 Cc: stable@vger.kernel.org Cc: Christian Kellner <ckellner@redhat.com> Fixes: 6f3badead6a0 ("thunderbolt: Hide authorized attribute if router does not support PCIe tunnels") Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Link: https://lore.kernel.org/r/20210727142501.27476-1-mika.westerberg@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-27perf cs-etm: Split --dump-raw-trace by AUX recordsJames Clark
Currently --dump-raw-trace skips queueing and splitting buffers because of an early exit condition in cs_etm__process_auxtrace_info(). Once that is removed we can print the split data by using the queues and searching for split buffers with the same reference as the one that is currently being processed. This keeps the same behaviour of dumping in file order when an AUXTRACE event appears, rather than moving trace dump to where AUX records are in the file. There will be a newline and size printout for each fragment. For example this buffer is comprised of two AUX records, but was printed as one: 0 0 0x8098 [0x30]: PERF_RECORD_AUXTRACE size: 0xa0 offset: 0 ref: 0x491a4dfc52fc0e6e idx: 0 t . ... CoreSight ETM Trace data: size 160 bytes Idx:0; ID:10; I_ASYNC : Alignment Synchronisation. Idx:12; ID:10; I_TRACE_INFO : Trace Info.; INFO=0x0 { CC.0 } Idx:17; ID:10; I_ADDR_L_64IS0 : Address, Long, 64 bit, IS0.; Addr=0x0000000000000000; Idx:80; ID:10; I_ASYNC : Alignment Synchronisation. Idx:92; ID:10; I_TRACE_INFO : Trace Info.; INFO=0x0 { CC.0 } Idx:97; ID:10; I_ADDR_L_64IS0 : Address, Long, 64 bit, IS0.; Addr=0xFFFFDE2AD3FD76D4; But is now printed as two fragments: 0 0 0x8098 [0x30]: PERF_RECORD_AUXTRACE size: 0xa0 offset: 0 ref: 0x491a4dfc52fc0e6e idx: 0 t . ... CoreSight ETM Trace data: size 80 bytes Idx:0; ID:10; I_ASYNC : Alignment Synchronisation. Idx:12; ID:10; I_TRACE_INFO : Trace Info.; INFO=0x0 { CC.0 } Idx:17; ID:10; I_ADDR_L_64IS0 : Address, Long, 64 bit, IS0.; Addr=0x0000000000000000; . ... CoreSight ETM Trace data: size 80 bytes Idx:80; ID:10; I_ASYNC : Alignment Synchronisation. Idx:92; ID:10; I_TRACE_INFO : Trace Info.; INFO=0x0 { CC.0 } Idx:97; ID:10; I_ADDR_L_64IS0 : Address, Long, 64 bit, IS0.; Addr=0xFFFFDE2AD3FD76D4; Decoding errors that appeared in problematic files are now not present, for example: Idx:808; ID:1c; I_BAD_SEQUENCE : Invalid Sequence in packet.[I_ASYNC] ... PKTP_ETMV4I_0016 : 0x0014 (OCSD_ERR_INVALID_PCKT_HDR) [Invalid packet header]; TrcIdx=822 Signed-off-by: James Clark <james.clark@arm.com> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Tested-by: Leo Yan <leo.yan@linaro.org> Cc: Al Grant <al.grant@arm.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Anshuman Khandual <anshuman.khandual@arm.com> Cc: Branislav Rankov <branislav.rankov@arm.com> Cc: Denis Nikitin <denik@chromium.org> Cc: Jiri Olsa <jolsa@redhat.com> Cc: John Garry <john.garry@huawei.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Mike Leach <mike.leach@linaro.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Suzuki Poulouse <suzuki.poulose@arm.com> Cc: Will Deacon <will@kernel.org> Cc: coresight@lists.linaro.org Cc: linux-arm-kernel@lists.infradead.org Link: http://lore.kernel.org/lkml/20210624164303.28632-3-james.clark@arm.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2021-07-27drm/msm/dp: Initialize dp->aux->drm_dev before registrationSean Paul
Avoids the following WARN: [ 3.009556] ------------[ cut here ]------------ [ 3.014306] WARNING: CPU: 7 PID: 109 at drivers/gpu/drm/drm_dp_helper.c:1796 drm_dp_aux_register+0xa4/0xac [ 3.024209] Modules linked in: [ 3.027351] CPU: 7 PID: 109 Comm: kworker/7:8 Not tainted 5.10.47 #69 [ 3.033958] Hardware name: Google Lazor (rev1 - 2) (DT) [ 3.039323] Workqueue: events deferred_probe_work_func [ 3.044596] pstate: 60c00009 (nZCv daif +PAN +UAO -TCO BTYPE=--) [ 3.050761] pc : drm_dp_aux_register+0xa4/0xac [ 3.055329] lr : dp_aux_register+0x40/0x88 [ 3.059538] sp : ffffffc010ad3920 [ 3.062948] x29: ffffffc010ad3920 x28: ffffffa64196ac70 [ 3.067239] mmc1: Command Queue Engine enabled [ 3.068406] x27: ffffffa64196ac68 x26: 0000000000000001 [ 3.068407] x25: 0000000000000002 x24: 0000000000000060 [ 3.068409] x23: ffffffa642ab3400 x22: ffffffe126c10e5b [ 3.068410] x21: ffffffa641dc3188 x20: ffffffa641963c10 [ 3.068412] x19: ffffffa642aba910 x18: 00000000ffff0a00 [ 3.068414] x17: 000000476f8e002a x16: 00000000000000b8 [ 3.073008] mmc1: new HS400 Enhanced strobe MMC card at address 0001 [ 3.078448] x15: ffffffffffffffff x14: ffffffffffffffff [ 3.078450] x13: 0000000000000030 x12: 0000000000000030 [ 3.078452] x11: 0101010101010101 x10: ffffffe12647a914 [ 3.078453] x9 : ffffffe12647a8cc x8 : 0000000000000000 [ 3.084452] mmcblk1: mmc1:0001 DA4032 29.1 GiB [ 3.089372] [ 3.089372] x7 : 6c6064717372fefe x6 : ffffffa642b11494 [ 3.089374] x5 : 0000000000000000 x4 : 6d006c657869ffff [ 3.089375] x3 : 000000006c657869 x2 : 000000000000000c [ 3.089376] x1 : ffffffe126c3ae3c x0 : ffffffa642aba910 [ 3.089381] Call trace: [ 3.094931] mmcblk1boot0: mmc1:0001 DA4032 partition 1 4.00 MiB [ 3.100291] drm_dp_aux_register+0xa4/0xac [ 3.100292] dp_aux_register+0x40/0x88 [ 3.100294] dp_display_bind+0x64/0xcc [ 3.100295] component_bind_all+0xdc/0x210 [ 3.100298] msm_drm_bind+0x1e8/0x5d4 [ 3.100301] try_to_bring_up_master+0x168/0x1b0 [ 3.105861] mmcblk1boot1: mmc1:0001 DA4032 partition 2 4.00 MiB [ 3.112282] __component_add+0xa0/0x158 [ 3.112283] component_add+0x1c/0x28 [ 3.112284] dp_display_probe+0x33c/0x380 [ 3.112286] platform_drv_probe+0x9c/0xbc [ 3.112287] really_probe+0x140/0x35c [ 3.112289] driver_probe_device+0x84/0xc0 [ 3.112292] __device_attach_driver+0x94/0xb0 [ 3.117967] mmcblk1rpmb: mmc1:0001 DA4032 partition 3 16.0 MiB, chardev (239:0) [ 3.123201] bus_for_each_drv+0x8c/0xd8 [ 3.123202] __device_attach+0xc4/0x150 [ 3.123204] device_initial_probe+0x1c/0x28 [ 3.123205] bus_probe_device+0x3c/0x9c [ 3.123206] deferred_probe_work_func+0x90/0xcc [ 3.123211] process_one_work+0x218/0x3ec [ 3.131976] mmcblk1: p1 p2 p3 p4 p5 p6 p7 p8 p9 p10 p11 p12 [ 3.134123] worker_thread+0x288/0x3e8 [ 3.134124] kthread+0x148/0x1b0 [ 3.134127] ret_from_fork+0x10/0x30 [ 3.134128] ---[ end trace cfb9fce3f70f824d ]--- Signed-off-by: Sean Paul <seanpaul@chromium.org> Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org> Link: https://lore.kernel.org/r/20210714152910.55093-1-sean@poorly.run Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-07-27drm/msm/dp: signal audio plugged change at dp_pm_resumeKuogee Hsieh
There is a scenario that dp cable is unplugged from DUT during system suspended will cause audio option state does not match real connection state. Fix this problem by Signaling audio plugged change with realtime connection status at dp_pm_resume() so that audio option will be in correct state after system resumed. Changes in V2: -- correct Fixes tag commit id. Fixes: f591dbb5fb8c ("drm/msm/dp: power off DP phy at suspend") Signed-off-by: Kuogee Hsieh <khsieh@codeaurora.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/1627059339-12142-1-git-send-email-khsieh@codeaurora.org Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-07-27drm/msm/dp: Initialize the INTF_CONFIG registerBjorn Andersson
Some bootloaders set the widebus enable bit in the INTF_CONFIG register, but configuration of widebus isn't yet supported ensure that the register has a known value, with widebus disabled. Fixes: c943b4948b58 ("drm/msm/dp: add displayPort driver support") Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20210722024434.3313167-1-bjorn.andersson@linaro.org Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-07-27drm/msm/dp: use dp_ctrl_off_link_stream during PHY compliance test runKuogee Hsieh
DP cable should always connect to DPU during the entire PHY compliance testing run. Since DP PHY compliance test is executed at irq_hpd event context, dp_ctrl_off_link_stream() should be used instead of dp_ctrl_off(). dp_ctrl_off() is used for unplug event which is triggered when DP cable is dis connected. Changes in V2: -- add fixes statement Fixes: f21c8a276c2d ("drm/msm/dp: handle irq_hpd with sink_count = 0 correctly") Signed-off-by: Kuogee Hsieh <khsieh@codeaurora.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/1626191647-13901-2-git-send-email-khsieh@codeaurora.org Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-07-27drm/msm: Fix display fault handlingRob Clark
It turns out that when the display is enabled by the bootloader, we can get some transient iommu faults from the display. Which doesn't go over too well when we install a fault handler that is gpu specific. To avoid this, defer installing the fault handler until we get around to setting up per-process pgtables (which is adreno_smmu specific). The arm-smmu fallback error reporting is sufficient for reporting display related faults (and in fact was all we had prior to f8f934c180f629bb927a04fd90d) Reported-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reported-by: Yassine Oudjana <y.oudjana@protonmail.com> Fixes: 2a574cc05d38 ("drm/msm: Improve the a6xx page fault handler") Signed-off-by: Rob Clark <robdclark@chromium.org> Tested-by: John Stultz <john.stultz@linaro.org> Tested-by: Yassine Oudjana <y.oudjana@protonmail.com> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20210707180113.840741-1-robdclark@gmail.com Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-07-27drm/msm/dpu: Fix sm8250_mdp register lengthRobert Foss
The downstream dts lists this value as 0x494, and not 0x45c. Fixes: af776a3e1c30 ("drm/msm/dpu: add SM8250 to hw catalog") Signed-off-by: Robert Foss <robert.foss@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org> Link: https://lore.kernel.org/r/20210628085033.9905-1-robert.foss@linaro.org Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-07-27virt: acrn: Do hcall_destroy_vm() before resource releaseShuo Liu
The ACRN hypervisor has scenarios which could run a real-time guest VM. The real-time guest VM occupies dedicated CPU cores, be assigned with dedicated PCI devices. It can run without the Service VM after boot up. hcall_destroy_vm() returns failure when a real-time guest VM refuses. The clearing of flag ACRN_VM_FLAG_DESTROYED causes some kernel resource double-freed in a later acrn_vm_destroy(). Do hcall_destroy_vm() before resource release to drop this chance to destroy the VM if hypercall fails. Fixes: 9c5137aedd11 ("virt: acrn: Introduce VM management interfaces") Cc: stable <stable@vger.kernel.org> Signed-off-by: Shuo Liu <shuo.a.liu@intel.com> Signed-off-by: Fei Li <fei1.li@intel.com> Link: https://lore.kernel.org/r/20210722062736.15050-1-fei1.li@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-27usb: otg-fsm: Fix hrtimer list corruptionDmitry Osipenko
The HNP work can be re-scheduled while it's still in-fly. This results in re-initialization of the busy work, resetting the hrtimer's list node of the work and crashing kernel with null dereference within kernel/timer once work's timer is expired. It's very easy to trigger this problem by re-plugging USB cable quickly. Initialize HNP work only once to fix this trouble. Unable to handle kernel NULL pointer dereference at virtual address 00000126) ... PC is at __run_timers.part.0+0x150/0x228 LR is at __next_timer_interrupt+0x51/0x9c ... (__run_timers.part.0) from [<c0187a2b>] (run_timer_softirq+0x2f/0x50) (run_timer_softirq) from [<c01013ad>] (__do_softirq+0xd5/0x2f0) (__do_softirq) from [<c012589b>] (irq_exit+0xab/0xb8) (irq_exit) from [<c0170341>] (handle_domain_irq+0x45/0x60) (handle_domain_irq) from [<c04c4a43>] (gic_handle_irq+0x6b/0x7c) (gic_handle_irq) from [<c0100b65>] (__irq_svc+0x65/0xac) Cc: stable@vger.kernel.org Acked-by: Peter Chen <peter.chen@kernel.org> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Link: https://lore.kernel.org/r/20210717182134.30262-6-digetx@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-27usb: host: ohci-at91: suspend/resume ports after/before OHCI accessesClaudiu Beznea
On SAMA7G5 suspending ports will cut the access to OHCI registers and any subsequent access to them will lead to CPU being blocked trying to access that memory. Same thing happens on resume: if OHCI memory is accessed before resuming ports the CPU will block on that access. The OCHI memory is accessed on suspend/resume though ohci_suspend()/ohci_resume(). Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210721132905.1970713-1-claudiu.beznea@microchip.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-27usb: musb: Fix suspend and resume issues for PHYs on I2C and SPITony Lindgren
As the USB PHYs typically are on I2C or SPI bus for the 2430 glue layer, we need configure the PHYs early for suspend. The musb glue layer we need to suspend only after musb_suspend() in suspend_late. Fixes: 62d472d8ad88 ("usb: musb: Add missing PM suspend and resume functions for 2430 glue") Reported-by: Andreas Kemnade <andreas@kemnade.info> Signed-off-by: Tony Lindgren <tony@atomide.com> Link: https://lore.kernel.org/r/20210727104134.52800-1-tony@atomide.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-27usb: gadget: f_hid: added GET_IDLE and SET_IDLE handlersMaxim Devaev
The USB HID standard declares mandatory support for GET_IDLE and SET_IDLE requests for Boot Keyboard. Most hosts can handle their absence, but others like some old/strange UEFIs and BIOSes consider this a critical error and refuse to work with f_hid. This primitive implementation of saving and returning idle is sufficient to meet the requirements of the standard and these devices. Acked-by: Felipe Balbi <balbi@kernel.org> Cc: stable <stable@vger.kernel.org> Signed-off-by: Maxim Devaev <mdevaev@gmail.com> Link: https://lore.kernel.org/r/20210721180351.129450-1-mdevaev@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-27usb: gadget: f_hid: fixed NULL pointer dereferencePhil Elwell
Disconnecting and reconnecting the USB cable can lead to crashes and a variety of kernel log spam. The problem was found and reproduced on the Raspberry Pi [1] and the original fix was created in Raspberry's own fork [2]. Link: https://github.com/raspberrypi/linux/issues/3870 [1] Link: https://github.com/raspberrypi/linux/commit/a6e47d5f4efbd2ea6a0b6565cd2f9b7bb217ded5 [2] Signed-off-by: Maxim Devaev <mdevaev@gmail.com> Signed-off-by: Phil Elwell <phil@raspberrypi.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210723155928.210019-1-mdevaev@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-27usb: gadget: remove leaked entry from udc driver listZhang Qilong
The usb_add_gadget_udc will add a new gadget to the udc class driver list. Not calling usb_del_gadget_udc in error branch will result in residual gadget entry in the udc driver list. We fix it by calling usb_del_gadget_udc to clean it when error return. Fixes: 48ba02b2e2b1 ("usb: gadget: add udc driver for max3420") Acked-by: Felipe Balbi <balbi@kernel.org> Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com> Link: https://lore.kernel.org/r/20210727073142.84666-1-zhangqilong3@huawei.com Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-27USB: usbtmc: Fix RCU stall warningQiang.zhang
rcu: INFO: rcu_preempt self-detected stall on CPU rcu: 1-...!: (2 ticks this GP) idle=d92/1/0x4000000000000000 softirq=25390/25392 fqs=3 (t=12164 jiffies g=31645 q=43226) rcu: rcu_preempt kthread starved for 12162 jiffies! g31645 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=0 rcu: Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior. rcu: RCU grace-period kthread stack dump: task:rcu_preempt state:R running task ........... usbtmc 3-1:0.0: unknown status received: -71 usbtmc 3-1:0.0: unknown status received: -71 usbtmc 3-1:0.0: unknown status received: -71 usbtmc 3-1:0.0: unknown status received: -71 usbtmc 3-1:0.0: unknown status received: -71 usbtmc 3-1:0.0: unknown status received: -71 usbtmc 3-1:0.0: unknown status received: -71 usbtmc 3-1:0.0: unknown status received: -71 usbtmc 3-1:0.0: usb_submit_urb failed: -19 The function usbtmc_interrupt() resubmits urbs when the error status of an urb is -EPROTO. In systems using the dummy_hcd usb controller this can result in endless interrupt loops when the usbtmc device is disconnected from the host system. Since host controller drivers already try to recover from transmission errors, there is no need to resubmit the urb or try other solutions to repair the error situation. In case of errors the INT pipe just stops to wait for further packets. Fixes: dbf3e7f654c0 ("Implement an ioctl to support the USMTMC-USB488 READ_STATUS_BYTE operation") Cc: stable@vger.kernel.org Reported-by: syzbot+e2eae5639e7203360018@syzkaller.appspotmail.com Signed-off-by: Qiang.zhang <qiang.zhang@windriver.com> Acked-by: Guido Kiener <guido.kiener@rohde-schwarz.com> Link: https://lore.kernel.org/r/20210723004334.458930-1-qiang.zhang@windriver.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>