aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2022-01-18random: remove unused extract_entropy() reserved argumentJason A. Donenfeld1-10/+7
This argument is always set to zero, as a result of us not caring about keeping a certain amount reserved in the pool these days. So just remove it and cleanup the function signatures. Reviewed-by: Dominik Brodowski <[email protected]> Signed-off-by: Jason A. Donenfeld <[email protected]>
2022-01-18random: remove incomplete last_data logicJason A. Donenfeld1-35/+4
There were a few things added under the "if (fips_enabled)" banner, which never really got completed, and the FIPS people anyway are choosing a different direction. Rather than keep around this halfbaked code, get rid of it so that we can focus on a single design of the RNG rather than two designs. Reviewed-by: Dominik Brodowski <[email protected]> Signed-off-by: Jason A. Donenfeld <[email protected]>
2022-01-18random: cleanup integer typesJason A. Donenfeld1-53/+52
Rather than using the userspace type, __uXX, switch to using uXX. And rather than using variously chosen `char *` or `unsigned char *`, use `u8 *` uniformly for things that aren't strings, in the case where we are doing byte-by-byte traversal. Reviewed-by: Dominik Brodowski <[email protected]> Signed-off-by: Jason A. Donenfeld <[email protected]>
2022-01-18random: cleanup poolinfo abstractionJason A. Donenfeld1-37/+30
Now that we're only using one polynomial, we can cleanup its representation into constants, instead of passing around pointers dynamically to select different polynomials. This improves the codegen and makes the code a bit more straightforward. Reviewed-by: Dominik Brodowski <[email protected]> Signed-off-by: Jason A. Donenfeld <[email protected]>
2022-01-18random: fix typo in commentsSchspa Shi1-1/+1
s/or/for Signed-off-by: Schspa Shi <[email protected]> Signed-off-by: Jason A. Donenfeld <[email protected]>
2022-01-18lib/crypto: sha1: re-roll loops to reduce code sizeJason A. Donenfeld1-81/+14
With SHA-1 no longer being used for anything performance oriented, and also soon to be phased out entirely, we can make up for the space added by unrolled BLAKE2s by simply re-rolling SHA-1. Since SHA-1 is so much more complex, re-rolling it more or less takes care of the code size added by BLAKE2s. And eventually, hopefully we'll see SHA-1 removed entirely from most small kernel builds. Cc: Herbert Xu <[email protected]> Cc: Ard Biesheuvel <[email protected]> Tested-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Jason A. Donenfeld <[email protected]>
2022-01-18lib/crypto: blake2s: move hmac construction into wireguardJason A. Donenfeld4-77/+39
Basically nobody should use blake2s in an HMAC construction; it already has a keyed variant. But unfortunately for historical reasons, Noise, used by WireGuard, uses HKDF quite strictly, which means we have to use this. Because this really shouldn't be used by others, this commit moves it into wireguard's noise.c locally, so that kernels that aren't using WireGuard don't get this superfluous code baked in. On m68k systems, this shaves off ~314 bytes. Cc: Herbert Xu <[email protected]> Tested-by: Geert Uytterhoeven <[email protected]> Acked-by: Ard Biesheuvel <[email protected]> Signed-off-by: Jason A. Donenfeld <[email protected]>
2022-01-18lib/crypto: add prompts back to crypto librariesJustin M. Forbes3-7/+14
Commit 6048fdcc5f269 ("lib/crypto: blake2s: include as built-in") took away a number of prompt texts from other crypto libraries. This makes values flip from built-in to module when oldconfig runs, and causes problems when these crypto libs need to be built in for thingslike BIG_KEYS. Fixes: 6048fdcc5f269 ("lib/crypto: blake2s: include as built-in") Cc: Herbert Xu <[email protected]> Cc: [email protected] Signed-off-by: Justin M. Forbes <[email protected]> [Jason: - moved menu into submenu of lib/ instead of root menu - fixed chacha sub-dependencies for CONFIG_CRYPTO] Signed-off-by: Jason A. Donenfeld <[email protected]>
2022-01-18Merge tag 'dmaengine-5.17-rc1' of ↵Linus Torvalds41-655/+1465
git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine Pull dmaengine updates from Vinod Koul: "A bunch of new support and few updates to drivers: New support: - DMA_MEMCPY_SG support is bought back as we have a user in Xilinx driver - Support for TI J721S2 SoC in k3-udma driver - Support for Ingenic MDMA and BDMA in the JZ4760 - Support for Renesas r8a779f0 dmac Updates: - We are finally getting rid of slave_id, so this brings in the changes across tree for that - updates for idxd driver - at_xdmac driver cleanup" * tag 'dmaengine-5.17-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine: (60 commits) dt-bindings: dma-controller: Split interrupt fields in example dmaengine: pch_dma: Remove usage of the deprecated "pci-dma-compat.h" API dmaengine: at_xdmac: Fix race over irq_status dmaengine: at_xdmac: Remove a level of indentation in at_xdmac_tasklet() dmaengine: at_xdmac: Fix at_xdmac_lld struct definition dmaengine: at_xdmac: Fix lld view setting dmaengine: at_xdmac: Remove a level of indentation in at_xdmac_advance_work() dmaengine: at_xdmac: Fix concurrency over xfers_list dmaengine: at_xdmac: Move the free desc to the tail of the desc list dmaengine: at_xdmac: Fix race for the tx desc callback dmaengine: at_xdmac: Fix concurrency over chan's completed_cookie dmaengine: at_xdmac: Print debug message after realeasing the lock dmaengine: at_xdmac: Start transfer for cyclic channels in issue_pending dmaengine: at_xdmac: Don't start transactions at tx_submit level dmaengine: idxd: deprecate token sysfs attributes for read buffers dmaengine: idxd: change bandwidth token to read buffers dmaengine: idxd: fix wq settings post wq disable dmaengine: idxd: change MSIX allocation based on per wq activation dmaengine: idxd: fix descriptor flushing locking dmaengine: idxd: embed irq_entry in idxd_wq struct ...
2022-01-18kernel/sched: Remove dl_boosted flag commentHui Su1-4/+0
since commit 2279f540ea7d ("sched/deadline: Fix priority inheritance with multiple scheduling classes"), we should not keep it here. Signed-off-by: Hui Su <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Daniel Bristot de Oliveira <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-01-18sched: Avoid double preemption in __cond_resched_*lock*()Peter Zijlstra1-9/+3
For PREEMPT/DYNAMIC_PREEMPT the *_unlock() will already trigger a preemption, no point in then calling preempt_schedule_common() *again*. Use _cond_resched() instead, since this is a NOP for the preemptible configs while it provide a preemption point for the others. Reported-by: xuhaifeng <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2022-01-18sched/fair: Fix all kernel-doc warningsRandy Dunlap1-3/+5
Quieten all kernel-doc warnings in kernel/sched/fair.c: kernel/sched/fair.c:3663: warning: No description found for return value of 'update_cfs_rq_load_avg' kernel/sched/fair.c:8601: warning: No description found for return value of 'asym_smt_can_pull_tasks' kernel/sched/fair.c:8673: warning: Function parameter or member 'sds' not described in 'update_sg_lb_stats' kernel/sched/fair.c:9483: warning: contents before sections Signed-off-by: Randy Dunlap <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Ricardo Neri <[email protected]> Acked-by: Vincent Guittot <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-01-18sched/core: Accounting forceidle time for all tasks except idle taskCruz Zhao2-3/+2
There are two types of forced idle time: forced idle time from cookie'd task and forced idle time form uncookie'd task. The forced idle time from uncookie'd task is actually caused by the cookie'd task in runqueue indirectly, and it's more accurate to measure the capacity loss with the sum of both. Assuming cpu x and cpu y are a pair of SMT siblings, consider the following scenarios: 1.There's a cookie'd task running on cpu x, and there're 4 uncookie'd tasks running on cpu y. For cpu x, there will be 80% forced idle time (from uncookie'd task); for cpu y, there will be 20% forced idle time (from cookie'd task). 2.There's a uncookie'd task running on cpu x, and there're 4 cookie'd tasks running on cpu y. For cpu x, there will be 80% forced idle time (from cookie'd task); for cpu y, there will be 20% forced idle time (from uncookie'd task). The scenario1 can recurrent by stress-ng(scenario2 can recurrent similary): (cookie'd)taskset -c x stress-ng -c 1 -l 100 (uncookie'd)taskset -c y stress-ng -c 4 -l 100 In the above two scenarios, the total capacity loss is 1 cpu, but in scenario1, the cookie'd forced idle time tells us 20% cpu capacity loss, in scenario2, the cookie'd forced idle time tells us 80% cpu capacity loss, which are not accurate. It'll be more accurate to measure with cookie'd forced idle time and uncookie'd forced idle time. Signed-off-by: Cruz Zhao <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Josh Don <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-01-18sched/pelt: Relax the sync of load_sum with load_avgVincent Guittot1-14/+22
Similarly to util_avg and util_sum, don't sync load_sum with the low bound of load_avg but only ensure that load_sum stays in the correct range. Signed-off-by: Vincent Guittot <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Dietmar Eggemann <[email protected]> Tested-by: Sachin Sant <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2022-01-18sched/pelt: Relax the sync of runnable_sum with runnable_avgVincent Guittot1-14/+19
Similarly to util_avg and util_sum, don't sync runnable_sum with the low bound of runnable_avg but only ensure that runnable_sum stays in the correct range. Signed-off-by: Vincent Guittot <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Dietmar Eggemann <[email protected]> Tested-by: Sachin Sant <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2022-01-18sched/pelt: Continue to relax the sync of util_sum with util_avgVincent Guittot1-7/+18
Rick reported performance regressions in bugzilla because of cpu frequency being lower than before: https://bugzilla.kernel.org/show_bug.cgi?id=215045 He bisected the problem to: commit 1c35b07e6d39 ("sched/fair: Ensure _sum and _avg values stay consistent") This commit forces util_sum to be synced with the new util_avg after removing the contribution of a task and before the next periodic sync. By doing so util_sum is rounded to its lower bound and might lost up to LOAD_AVG_MAX-1 of accumulated contribution which has not yet been reflected in util_avg. update_tg_cfs_util() is not the only place where we round util_sum and lost some accumulated contributions that are not already reflected in util_avg. Modify update_tg_cfs_util() and detach_entity_load_avg() to not sync util_sum with the new util_avg. Instead of always setting util_sum to the low bound of util_avg, which can significantly lower the utilization, we propagate the difference. In addition, we also check that cfs's util_sum always stays above the lower bound for a given util_avg as it has been observed that sched_entity's util_sum is sometimes above cfs one. Signed-off-by: Vincent Guittot <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Dietmar Eggemann <[email protected]> Tested-by: Sachin Sant <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2022-01-18sched/pelt: Relax the sync of util_sum with util_avgVincent Guittot2-4/+16
Rick reported performance regressions in bugzilla because of cpu frequency being lower than before: https://bugzilla.kernel.org/show_bug.cgi?id=215045 He bisected the problem to: commit 1c35b07e6d39 ("sched/fair: Ensure _sum and _avg values stay consistent") This commit forces util_sum to be synced with the new util_avg after removing the contribution of a task and before the next periodic sync. By doing so util_sum is rounded to its lower bound and might lost up to LOAD_AVG_MAX-1 of accumulated contribution which has not yet been reflected in util_avg. Instead of always setting util_sum to the low bound of util_avg, which can significantly lower the utilization of root cfs_rq after propagating the change down into the hierarchy, we revert the change of util_sum and propagate the difference. In addition, we also check that cfs's util_sum always stays above the lower bound for a given util_avg as it has been observed that sched_entity's util_sum is sometimes above cfs one. Fixes: 1c35b07e6d39 ("sched/fair: Ensure _sum and _avg values stay consistent") Reported-by: Rick Yiu <[email protected]> Signed-off-by: Vincent Guittot <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Dietmar Eggemann <[email protected]> Tested-by: Sachin Sant <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2022-01-18psi: Fix uaf issue when psi trigger is destroyed while being polledSuren Baghdasaryan5-45/+40
With write operation on psi files replacing old trigger with a new one, the lifetime of its waitqueue is totally arbitrary. Overwriting an existing trigger causes its waitqueue to be freed and pending poll() will stumble on trigger->event_wait which was destroyed. Fix this by disallowing to redefine an existing psi trigger. If a write operation is used on a file descriptor with an already existing psi trigger, the operation will fail with EBUSY error. Also bypass a check for psi_disabled in the psi_trigger_destroy as the flag can be flipped after the trigger is created, leading to a memory leak. Fixes: 0e94682b73bf ("psi: introduce psi monitor") Reported-by: [email protected] Suggested-by: Linus Torvalds <[email protected]> Analyzed-by: Eric Biggers <[email protected]> Signed-off-by: Suren Baghdasaryan <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Eric Biggers <[email protected]> Acked-by: Johannes Weiner <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected]
2022-01-18x86/perf: Avoid warning for Arch LBR without XSAVEAndi Kleen1-0/+3
Some hypervisors support Arch LBR, but without the LBR XSAVE support. The current Arch LBR init code prints a warning when the xsave size (0) is unexpected. Avoid printing the warning for the "no LBR XSAVE" case. Signed-off-by: Andi Kleen <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2022-01-18perf/x86/intel/uncore: Add IMC uncore support for ADLKan Liang5-5/+220
Current ADL uncore code only supports the legacy IMC (memory controller) free-running counters. Besides the free-running counters, ADL also supports several general purpose-counters. The general-purpose counters can also be accessed via MMIO but in a different location. Factor out __uncore_imc_init_box() with offset as a parameter. The function can be shared between ADL and TGL. The event format and the layout of the control registers are a little bit different from other uncore counters. The intel_generic_uncore_mmio_enable_event() can be shared with client IMC uncore. Expose the function. Add more PCI IDs for ADL machines. Fixes: 772ed05f3c5c ("perf/x86/intel/uncore: Add Alder Lake support") Signed-off-by: Kan Liang <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2022-01-18perf/x86/intel/lbr: Add static_branch for LBR INFO flagsPeter Zijlstra (Intel)1-17/+34
Using static_branch to replace the LBR INFO flags to optimize the LBR INFO parsing. Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Signed-off-by: Kan Liang <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Tested-by: Kan Liang <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2022-01-18perf/x86/intel/lbr: Support LBR format V7Peter Zijlstra (Intel)3-51/+75
The Goldmont plus and Tremont have LBR format V7. The V7 has LBR_INFO, which is the same as LBR format V5. But V7 doesn't support TSX. Without the patch, the associated misprediction and cycles information in the LBR_INFO may be lost on a Goldmont plus platform. For Tremont, the patch only impacts the non-PEBS events. Because of the adaptive PEBS, the LBR_INFO is always processed for a PEBS event. Currently, two different ways are used to check the LBR capabilities, which make the codes complex and confusing. For the LBR format V4 and earlier, the global static lbr_desc array is used to store the flags for the LBR capabilities in each LBR format. For LBR format V5 and V6, the current code checks the version number for the LBR capabilities. There are common LBR capabilities among LBR format versions. Several flags for the LBR capabilities are introduced into the struct x86_pmu. The flags, which can be shared among LBR formats, are used to check the LBR capabilities. Add intel_pmu_lbr_init() to set the flags accordingly at boot time. Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Signed-off-by: Kan Liang <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Tested-by: Kan Liang <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2022-01-18perf/x86/rapl: fix AMD event handlingStephane Eranian1-3/+6
The RAPL events exposed under /sys/devices/power/events should only reflect what the underlying hardware actually support. This is how it works on Intel RAPL and Intel core/uncore PMUs in general. But on AMD, this was not the case. All possible RAPL events were advertised. This is what it showed on an AMD Fam17h: $ ls /sys/devices/power/events/ energy-cores energy-gpu energy-pkg energy-psys energy-ram energy-cores.scale energy-gpu.scale energy-pkg.scale energy-psys.scale energy-ram.scale energy-cores.unit energy-gpu.unit energy-pkg.unit energy-psys.unit energy-ram.unit Yet, on AMD Fam17h, only energy-pkg is supported. This patch fixes the problem. Given the way perf_msr_probe() works, the amd_rapl_msrs[] table has to have all entries filled out and in particular the group field, otherwise perf_msr_probe() defaults to making the event visible. With the patch applied, the kernel now only shows was is actually supported: $ ls /sys/devices/power/events/ energy-pkg energy-pkg.scale energy-pkg.unit The patch also uses the RAPL_MSR_MASK because only the 32-bits LSB of the RAPL counters are relevant when reading power consumption. Signed-off-by: Stephane Eranian <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2022-01-18perf/x86/intel/uncore: Fix CAS_COUNT_WRITE issue for ICXZhengjun Xing1-1/+1
The user recently report a perf issue in the ICX platform, when test by perf event “uncore_imc_x/cas_count_write”,the write bandwidth is always very small (only 0.38MB/s), it is caused by the wrong "umask" for the "cas_count_write" event. When double-checking, find "cas_count_read" also is wrong. The public document for ICX uncore: 3rd Gen Intel® Xeon® Processor Scalable Family, Codename Ice Lake,Uncore Performance Monitoring Reference Manual, Revision 1.00, May 2021 On 2.4.7, it defines Unit Masks for CAS_COUNT: RD b00001111 WR b00110000 So corrected both "cas_count_read" and "cas_count_write" for ICX. Old settings: hswep_uncore_imc_events INTEL_UNCORE_EVENT_DESC(cas_count_read, "event=0x04,umask=0x03") INTEL_UNCORE_EVENT_DESC(cas_count_write, "event=0x04,umask=0x0c") New settings: snr_uncore_imc_events INTEL_UNCORE_EVENT_DESC(cas_count_read, "event=0x04,umask=0x0f") INTEL_UNCORE_EVENT_DESC(cas_count_write, "event=0x04,umask=0x30") Fixes: 2b3b76b5ec67 ("perf/x86/intel/uncore: Add Ice Lake server uncore support") Signed-off-by: Zhengjun Xing <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Adrian Hunter <[email protected]> Reviewed-by: Kan Liang <[email protected]> Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected]
2022-01-18perf/x86/intel: Add a quirk for the calculation of the number of counters on ↵Kan Liang1-0/+13
Alder Lake For some Alder Lake machine with all E-cores disabled in a BIOS, the below warning may be triggered. [ 2.010766] hw perf events fixed 5 > max(4), clipping! Current perf code relies on the CPUID leaf 0xA and leaf 7.EDX[15] to calculate the number of the counters and follow the below assumption. For a hybrid configuration, the leaf 7.EDX[15] (X86_FEATURE_HYBRID_CPU) is set. The leaf 0xA only enumerate the common counters. Linux perf has to manually add the extra GP counters and fixed counters for P-cores. For a non-hybrid configuration, the X86_FEATURE_HYBRID_CPU should not be set. The leaf 0xA enumerates all counters. However, that's not the case when all E-cores are disabled in a BIOS. Although there are only P-cores in the system, the leaf 7.EDX[15] (X86_FEATURE_HYBRID_CPU) is still set. But the leaf 0xA is updated to enumerate all counters of P-cores. The inconsistency triggers the warning. Several software ways were considered to handle the inconsistency. - Drop the leaf 0xA and leaf 7.EDX[15] CPUID enumeration support. Hardcode the number of counters. This solution may be a problem for virtualization. A hypervisor cannot control the number of counters in a Linux guest via changing the guest CPUID enumeration anymore. - Find another CPUID bit that is also updated with E-cores disabled. There may be a problem in the virtualization environment too. Because a hypervisor may disable the feature/CPUID bit. - The P-cores have a maximum of 8 GP counters and 4 fixed counters on ADL. The maximum number can be used to detect the case. This solution is implemented in this patch. Fixes: ee72a94ea4a6 ("perf/x86/intel: Fix fixed counter check warning for some Alder Lake") Reported-by: Damjan Marion (damarion) <[email protected]> Reported-by: Chan Edison <[email protected]> Signed-off-by: Kan Liang <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Tested-by: Damjan Marion (damarion) <[email protected]> Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected]
2022-01-18perf: Fix perf_event_read_local() timePeter Zijlstra2-112/+149
Time readers that cannot take locks (due to NMI etc..) currently make use of perf_event::shadow_ctx_time, which, for that event gives: time' = now + (time - timestamp) or, alternatively arranged: time' = time + (now - timestamp) IOW, the progression of time since the last time the shadow_ctx_time was updated. There's problems with this: A) the shadow_ctx_time is per-event, even though the ctx_time it reflects is obviously per context. The direct concequence of this is that the context needs to iterate all events all the time to keep the shadow_ctx_time in sync. B) even with the prior point, the context itself might not be active meaning its time should not advance to begin with. C) shadow_ctx_time isn't consistently updated when ctx_time is There are 3 users of this stuff, that suffer differently from this: - calc_timer_values() - perf_output_read() - perf_event_update_userpage() /* A */ - perf_event_read_local() /* A,B */ In particular, perf_output_read() doesn't suffer at all, because it's sample driven and hence only relevant when the event is actually running. This same was supposed to be true for perf_event_update_userpage(), after all self-monitoring implies the context is active *HOWEVER*, as per commit f79256532682 ("perf/core: fix userpage->time_enabled of inactive events") this goes wrong when combined with counter overcommit, in that case those events that do not get scheduled when the context becomes active (task events typically) miss out on the EVENT_TIME update and ENABLED time is inflated (for a little while) with the time the context was inactive. Once the event gets rotated in, this gets corrected, leading to a non-monotonic timeflow. perf_event_read_local() made things even worse, it can request time at any point, suffering all the problems perf_event_update_userpage() does and more. Because while perf_event_update_userpage() is limited by the context being active, perf_event_read_local() users have no such constraint. Therefore, completely overhaul things and do away with perf_event::shadow_ctx_time. Instead have regular context time updates keep track of this offset directly and provide perf_event_time_now() to complement perf_event_time(). perf_event_time_now() will, in adition to being context wide, also take into account if the context is active. For inactive context, it will not advance time. This latter property means the cgroup perf_cgroup_info context needs to grow addition state to track this. Additionally, since all this is strictly per-cpu, we can use barrier() to order context activity vs context time. Fixes: 7d9285e82db5 ("perf/bpf: Extend the perf_event_read_local() interface, a.k.a. "bpf: perf event change needed for subsequent bpf helpers"") Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Tested-by: Song Liu <[email protected]> Tested-by: Namhyung Kim <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2022-01-18KVM: VMX: switch blocked_vcpu_on_cpu_lock to raw spinlockMarcelo Tosatti1-8/+8
blocked_vcpu_on_cpu_lock is taken from hard interrupt context (pi_wakeup_handler), therefore it cannot sleep. Switch it to a raw spinlock. Fixes: [41297.066254] BUG: scheduling while atomic: CPU 0/KVM/635218/0x00010001 [41297.066323] Preemption disabled at: [41297.066324] [<ffffffff902ee47f>] irq_enter_rcu+0xf/0x60 [41297.066339] Call Trace: [41297.066342] <IRQ> [41297.066346] dump_stack_lvl+0x34/0x44 [41297.066353] ? irq_enter_rcu+0xf/0x60 [41297.066356] __schedule_bug.cold+0x7d/0x8b [41297.066361] __schedule+0x439/0x5b0 [41297.066365] ? task_blocks_on_rt_mutex.constprop.0.isra.0+0x1b0/0x440 [41297.066369] schedule_rtlock+0x1e/0x40 [41297.066371] rtlock_slowlock_locked+0xf1/0x260 [41297.066374] rt_spin_lock+0x3b/0x60 [41297.066378] pi_wakeup_handler+0x31/0x90 [kvm_intel] [41297.066388] sysvec_kvm_posted_intr_wakeup_ipi+0x9d/0xd0 [41297.066392] </IRQ> [41297.066392] asm_sysvec_kvm_posted_intr_wakeup_ipi+0x12/0x20 ... Signed-off-by: Marcelo Tosatti <[email protected]> Cc: [email protected] Signed-off-by: Paolo Bonzini <[email protected]>
2022-01-18Merge tag 'ata-5.17-rc1' of ↵Linus Torvalds59-1439/+1272
git://git.kernel.org/pub/scm/linux/kernel/git/dlemoal/libata Pull ATA updates from Damien Le Moal: "A larger than usual set of changes for this cycle. The bulk of the changes are part of a rework of libata messages and debugging features from Hannes. In more detail, the changes are as follows. - Small code cleanups in the pata_ali driver (unnecessary variable initialization and simplified return statement, from Jason and Colin. - Switch to using struct_group() in the sata_fsl driver, from Kees. - Convert many sysfs attribute show functions to use sysfs_emit() instead of snprintf(), from me. - sata_dwc_460ex driver code cleanups, from Andy. - Improve DMA setup and remove superfluous error message in libahci_platform, from Andy - A small code cleanup in libata to use min() instead of open coding test, from Changcheng. - Rework of libata messages from Hannes. This is especially focused on replacing compile time defined debugging messages (DPRINTK() and VPRINTK()) with regular dynamic debugging messages (pr_debug()) and traceipoint events. Both libata-core and many drivers are updated to have a consistent debugging level control for all drivers. - Extend compile test support to as many drivers as possible in ATA Kconfig to improve compile test coverage, from me. - Fixes to avoid compile time warnings (W=1) and sparse warnings in sata_fsl and ahci_xgene drivers, from me. - Fix the interface of the read_id() port operation method to clarify that the data buffer passed as an argument is little endian. This avoids sparse warnings in the pata_netcell, pata_it821x, ahci_xgene, ahci_cevaxi and ahci_brcm drivers. From me. - Small code cleanup in the pata_octeon_cf driver, from Minghao. - Improved IRQ configuration code in pata_of_platform, from Lad. - Simplified implementation of __ata_scsi_queuecmd(), from Wenchao. - Debounce delay flag renaming, from Paul. - Add support for AMD A85 FCH (Hudson D4) AHCI adapters, from Paul" * tag 'ata-5.17-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/dlemoal/libata: (106 commits) ata: pata_ali: remove redundant return statement ata: ahci: Add support for AMD A85 FCH (Hudson D4) ata: libata: Rename link flag ATA_LFLAG_NO_DB_DELAY ata: libata-scsi: simplify __ata_scsi_queuecmd() ata: pata_of_platform: Use platform_get_irq_optional() to get the interrupt ata: pata_samsung_cf: add compile test support ata: pata_pxa: add compile test support ata: pata_imx: add compile test support ata: pata_ftide010: add compile test support ata: pata_cs5535: add compile test support ata: pata_octeon_cf: remove redundant val variable ata: fix read_id() ata port operation interface ata: ahci_xgene: use correct type for port mmio address ata: sata_fsl: fix cmdhdr_tbl_entry and prde struct definitions ata: sata_fsl: fix scsi host initialization ata: pata_bk3710: add compile test support ata: ahci_seattle: add compile test support ata: ahci_xgene: add compile test support ata: ahci_tegra: add compile test support ata: ahci_sunxi: add compile test support ...
2022-01-18Merge tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhostLinus Torvalds47-237/+578
Pull virtio updates from Michael Tsirkin: "virtio,vdpa,qemu_fw_cfg: features, cleanups, and fixes. - partial support for < MAX_ORDER - 1 granularity for virtio-mem - driver_override for vdpa - sysfs ABI documentation for vdpa - multiqueue config support for mlx5 vdpa - and misc fixes, cleanups" * tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost: (42 commits) vdpa/mlx5: Fix tracking of current number of VQs vdpa/mlx5: Fix is_index_valid() to refer to features vdpa: Protect vdpa reset with cf_mutex vdpa: Avoid taking cf_mutex lock on get status vdpa/vdpa_sim_net: Report max device capabilities vdpa: Use BIT_ULL for bit operations vdpa/vdpa_sim: Configure max supported virtqueues vdpa/mlx5: Report max device capabilities vdpa: Support reporting max device capabilities vdpa/mlx5: Restore cur_num_vqs in case of failure in change_num_qps() vdpa: Add support for returning device configuration information vdpa/mlx5: Support configuring max data virtqueue vdpa/mlx5: Fix config_attr_mask assignment vdpa: Allow to configure max data virtqueues vdpa: Read device configuration only if FEATURES_OK vdpa: Sync calls set/get config/status with cf_mutex vdpa/mlx5: Distribute RX virtqueues in RQT object vdpa: Provide interface to read driver features vdpa: clean up get_config_size ret value handling virtio_ring: mark ring unused on error ...
2022-01-18Merge tag 'rproc-v5.17' of ↵Linus Torvalds20-21/+400
git://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux Pull remoteproc updates from Bjorn Andersson: "This introduces support for controlling the Cortex R7 co-processor in Renesas Gen3, support for R5F clusters and C71x DSPs on TI J721S2 and compute, audio and modem subsystems on Qualcomm SM6350. It fixes a couple of sparse errors related to memcpy_to/fromio and corrects the kerneldoc spelling of "Return:". The stm32 driver no longer attempts to communicate with the remote after the firmware has crashed" * tag 'rproc-v5.17' of git://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux: (22 commits) remoteproc: stm32: Improve crash recovery time remoteproc: rcar_rproc: Remove trailing semicolon remoteproc: rcar_rproc: Fix pm_runtime_get_sync error check remoteproc: qcom: pas: Add SM6350 CDSP support remoteproc: qcom: pas: Add SM6350 ADSP support remoteproc: qcom: pas: Add SM6350 MPSS support dt-bindings: remoteproc: qcom: pas: Add SM6350 adsp, cdsp & mpss remoteproc: qcom: pas: Add missing power-domain "mxc" for CDSP remoteproc: imx_rproc: correct firmware reload remoteproc: qcom: pil_info: Don't memcpy_toio more than is provided remoteproc: Add Renesas rcar driver dt-bindings: remoteproc: Add Renesas R-Car remoteproc: Fix remaining wrong return formatting in documentation MAINTAINERS: Removing Ohad from remoteproc/rpmsg maintenance remoteproc: ingenic: Request IRQ disabled remoteproc: k3-r5: Extend support for R5F clusters on J721S2 SoCs remoteproc: k3-dsp: Extend support for C71x DSPs on J721S2 SoCs dt-bindings: remoteproc: k3-dsp: Update bindings for J721S2 SoCs dt-bindings: remoteproc: k3-r5f: Update bindings for J721S2 SoCs remoteproc: coredump: Correct argument 2 type for memcpy_fromio ...
2022-01-18Merge tag 'rpmsg-v5.17' of ↵Linus Torvalds5-21/+36
git://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux Pull rpmsg updates from Bjorn Andersson: "This adds pr_fmt for the rpmsg_char driver, fixes error handling in rpmsg_dev_probe() and corrects the spelling of "Return:" in various places, in order to fix kerneldoc" * tag 'rpmsg-v5.17' of git://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux: rpmsg: core: Clean up resources on announce_create failure. rpmsg: Fix documentation return formatting rpmsg: char: Add pr_fmt() to prefix messages
2022-01-18vfs: fs_context: fix up param length parsing in legacy_parse_paramJamie Hill-Daniel1-1/+1
The "PAGE_SIZE - 2 - size" calculation in legacy_parse_param() is an unsigned type so a large value of "size" results in a high positive value instead of a negative value as expected. Fix this by getting rid of the subtraction. Signed-off-by: Jamie Hill-Daniel <[email protected]> Signed-off-by: William Liu <[email protected]> Tested-by: Salvatore Bonaccorso <[email protected]> Tested-by: Thadeu Lima de Souza Cascardo <[email protected]> Acked-by: Dan Carpenter <[email protected]> Acked-by: Al Viro <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2022-01-18Merge tag 'pm-5.17-rc1-2' of ↵Linus Torvalds7-29/+71
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull more power management updates from Rafael Wysocki: "This is a continuation of the rework of device power management macros used for declaring device power management callbacks (Paul Cercueil)" * tag 'pm-5.17-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: iio: pressure: bmp280: Use new PM macros PM: runtime: Add EXPORT[_GPL]_RUNTIME_DEV_PM_OPS macros PM: runtime: Add DEFINE_RUNTIME_DEV_PM_OPS() macro PM: core: Add EXPORT[_GPL]_SIMPLE_DEV_PM_OPS macros PM: core: Remove static qualifier in DEFINE_SIMPLE_DEV_PM_OPS macro PM: core: Remove DEFINE_UNIVERSAL_DEV_PM_OPS() macro
2022-01-18Merge tag 'acpi-5.17-rc1-2' of ↵Linus Torvalds19-62/+1997
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull more ACPI updates from Rafael Wysocki: "The most significant item here is the Platform Firmware Runtime Update and Telemetry (PFRUT) support designed to allow certain pieces of the platform firmware to be updated on the fly, among other things. Also important is the e820 handling change on x86 that should work around PCI BAR allocation issues on some systems shipping since 2019. The rest is just a handful of assorted fixes and cleanups on top of the ACPI material merged previously. Specifics: - Add support for the the Platform Firmware Runtime Update and Telemetry (PFRUT) interface based on ACPI to allow certain pieces of the platform firmware to be updated without restarting the system and to provide a mechanism for collecting platform firmware telemetry data (Chen Yu, Dan Carpenter, Yang Yingliang). - Ignore E820 reservations covering PCI host bridge windows on sufficiently recent x86 systems to avoid issues with allocating PCI BARs on systems where the E820 reservations cover the entire PCI host bridge memory window returned by the _CRS object in the system's ACPI tables (Hans de Goede). - Fix and clean up acpi_scan_init() (Rafael Wysocki). - Add more sanity checking to ACPI SPCR tables parsing (Mark Langsdorf). - Fix up ACPI APD (AMD Soc) driver initialization (Jiasheng Jiang). - Drop unnecessary "static" from the ACPI PCC address space handling driver added recently (kernel test robot)" * tag 'acpi-5.17-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: ACPI: PCC: pcc_ctx can be static ACPI: scan: Rename label in acpi_scan_init() ACPI: scan: Simplify initialization of power and sleep buttons ACPI: scan: Change acpi_scan_init() return value type to void ACPI: SPCR: check if table->serial_port.access_width is too wide ACPI: APD: Check for NULL pointer after calling devm_ioremap() x86/PCI: Ignore E820 reservations for bridge windows on newer systems ACPI: pfr_telemetry: Fix info leak in pfrt_log_ioctl() ACPI: pfr_update: Fix return value check in pfru_write() ACPI: tools: Introduce utility for firmware updates/telemetry ACPI: Introduce Platform Firmware Runtime Telemetry driver ACPI: Introduce Platform Firmware Runtime Update device driver efi: Introduce EFI_FIRMWARE_MANAGEMENT_CAPSULE_HEADER and corresponding structures
2022-01-18cifs: serialize all mount attemptsRonnie Sahlberg1-1/+7
RHBZ: 2008434 Some servers, such as Windows2016 have a very low number of concurrent mounts that they allow from each client. This can be a problem if you have a more than a handful (==3 in this case) of cifs entries in your fstab and cause a number of the mounts there to randomly fail. Add a global mutex and use it to serialize all mount attempts. Signed-off-by: Ronnie Sahlberg <[email protected]> Signed-off-by: Steve French <[email protected]>
2022-01-18Merge tag 'slab-for-5.17-part2' of ↵Linus Torvalds3-71/+0
git://git.kernel.org/pub/scm/linux/kernel/git/vbabka/slab Pull more slab updates from Vlastimil Babka: "Finish the conversion to struct slab by removing slab-specific fields from struct page. The first slab update (see merge commit ca1a46d6f506) did most of the conversion, but there was also series in iommu tree removing the iommu's usage of struct page 'freelist' field, blocking the final struct page cleanup. Now that the iommu changes have been merged, we can finish the job" * tag 'slab-for-5.17-part2' of git://git.kernel.org/pub/scm/linux/kernel/git/vbabka/slab: mm: Remove slab from struct page
2022-01-18Merge tag 'arc-5.17-rc1' of ↵Linus Torvalds8-179/+178
git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc Pull ARC fixes from Vineet Gupta: "Nothing too exciting for now" * tag 'arc-5.17-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc: arc: use swap() to make code cleaner arc: perf: Move static structs to where they're really used ARC: perf: fix misleading comment about pmu vs counter stop arc: Replace lkml.org links with lore ARC: perf: Remove redundant initialization of variable idx ARC: thread_info.h: correct two typos in a comment
2022-01-18Merge tag 'perf-tools-for-v5.17-2022-01-16' of ↵Linus Torvalds153-2175/+4685
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux Pull perf tool updates from Arnaldo Carvalho de Melo: "New features: - Add 'trace' subcommand for 'perf ftrace', setting the stage for more 'perf ftrace' subcommands. Not using a subcommand yields the previous behaviour of 'perf ftrace'. - Add 'latency' subcommand to 'perf ftrace', that can use the function graph tracer or a BPF optimized one, via the -b/--use-bpf option. E.g.: $ sudo perf ftrace latency -a -T mutex_lock sleep 1 # DURATION | COUNT | GRAPH | 0 - 1 us | 4596 | ######################## | 1 - 2 us | 1680 | ######### | 2 - 4 us | 1106 | ##### | 4 - 8 us | 546 | ## | 8 - 16 us | 562 | ### | 16 - 32 us | 1 | | 32 - 64 us | 0 | | 64 - 128 us | 0 | | 128 - 256 us | 0 | | 256 - 512 us | 0 | | 512 - 1024 us | 0 | | 1 - 2 ms | 0 | | 2 - 4 ms | 0 | | 4 - 8 ms | 0 | | 8 - 16 ms | 0 | | 16 - 32 ms | 0 | | 32 - 64 ms | 0 | | 64 - 128 ms | 0 | | 128 - 256 ms | 0 | | 256 - 512 ms | 0 | | 512 - 1024 ms | 0 | | 1 - ... s | 0 | | The original implementation of this command was in the bcc tool. - Support --cputype option for hybrid events in 'perf stat'. Improvements: - Call chain improvements for ARM64. - No need to do any affinity setup when profiling pids. - Reduce multiplexing with duration_time in 'perf stat' metrics. - Improve error message for uncore events, stating that some event groups are can only be used in system wide (-a) mode. - perf stat metric group leader fixes/improvements, including arch specific changes to better support Intel topdown events. - Probe non-deprecated sysfs path first, i.e. try the path /sys/devices/system/cpu/cpuN/topology/thread_siblings first, then the old /sys/devices/system/cpu/cpuN/topology/core_cpus. - Disable debuginfod by default in 'perf record', to avoid stalls on distros such as Fedora 35. - Use unbuffered output in 'perf bench' when pipe/tee'ing to a file. - Enable ignore_missing_thread in 'perf trace' Fixes: - Avoid TUI crash when navigating in the annotation of recursive functions. - Fix hex dump character output in 'perf script'. - Fix JSON indentation to 4 spaces standard in the ARM vendor event files. - Fix use after free in metric__new(). - Fix IS_ERR_OR_NULL() usage in the perf BPF loader. - Fix up cross-arch register support, i.e. when printing register names take into account the architecture where the perf.data file was collected. - Fix SMT fallback with large core counts. - Don't lower case MetricExpr when parsing JSON files so as not to lose info such as the ":G" event modifier in metrics. perf test: - Add basic stress test for sigtrap handling to 'perf test'. - Fix 'perf test' failures on s/390 - Enable system wide for metricgroups test in 'perf test´. - Use 3 digits for test numbering now we can have more tests. Arch specific: - Add events for Arm Neoverse N2 in the ARM JSON vendor event files - Support PERF_MEM_LVLNUM encodings in powerpc, that came from a single patch series, where I incorrectly merged the kernel bits, that were then reverted after coordination with Michael Ellerman and Stephen Rothwell. - Add ARM SPE total latency as PERF_SAMPLE_WEIGHT. - Update AMD documentation, with info on raw event encoding. - Add support for global and local variants of the "p_stage_cyc" sort key, applicable to perf.data files collected on powerpc. - Remove duplicate and incorrect aux size checks in the ARM CoreSight ETM code. Refactorings: - Add a perf_cpu abstraction to disambiguate CPUs and CPU map indexes, fixing problems along the way. - Document CPU map methods. UAPI sync: - Update arch/x86/lib/mem{cpy,set}_64.S copies used in 'perf bench mem memcpy' - Sync UAPI files with the kernel sources: drm, msr-index, cpufeatures. Build system - Enable warnings through HOSTCFLAGS. - Drop requirement for libstdc++.so for libopencsd check libperf: - Make libperf adopt perf_counts_values__scale() from tools/perf/util/. - Add a stat multiplexing test to libperf" * tag 'perf-tools-for-v5.17-2022-01-16' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux: (115 commits) perf record: Disable debuginfod by default perf evlist: No need to do any affinity setup when profiling pids perf cpumap: Add is_dummy() method perf metric: Fix metric_leader perf cputopo: Fix CPU topology reading on s/390 perf metricgroup: Fix use after free in metric__new() libperf tests: Update a use of the new cpumap API perf arm: Fix off-by-one directory path tools arch x86: Sync the msr-index.h copy with the kernel sources tools headers cpufeatures: Sync with the kernel sources tools headers UAPI: Update tools's copy of drm.h header tools arch: Update arch/x86/lib/mem{cpy,set}_64.S copies used in 'perf bench mem memcpy' perf pmu-events: Don't lower case MetricExpr perf expr: Add debug logging for literals perf tools: Probe non-deprecated sysfs path 1st perf tools: Fix SMT fallback with large core counts perf cpumap: Give CPUs their own type perf stat: Correct first_shadow_cpu to return index perf script: Fix flipped index and cpu perf c2c: Use more intention revealing iterator ...
2022-01-18Merge tag 'for-linus-5.17-ofs-1' of ↵Linus Torvalds2-11/+17
git://git.kernel.org/pub/scm/linux/kernel/git/hubcap/linux Pull orangefs fixes from Mike Marshall: "Two fixes: - Fix the size of a memory allocation in orangefs_bufmap_alloc() (Christophe JAILLET) - Use default_groups in kobj_type (Greg KH)" * tag 'for-linus-5.17-ofs-1' of git://git.kernel.org/pub/scm/linux/kernel/git/hubcap/linux: orangefs: Fix the size of a memory allocation in orangefs_bufmap_alloc() orangefs: use default_groups in kobj_type
2022-01-18powerpc/64s: Mask SRR0 before checking against the masked NIPNicholas Piggin1-0/+2
Commit 314f6c23dd8d ("powerpc/64s: Mask NIP before checking against SRR0") masked off the low 2 bits of the NIP value in the interrupt stack frame in case they are non-zero and mis-compare against a SRR0 register value of a CPU which always reads back 0 from the 2 low bits which are reserved. This now causes the opposite problem that an implementation which does implement those bits in SRR0 will mis-compare against the masked NIP value in which they have been cleared. QEMU is one such implementation, and this is allowed by the architecture. This can be triggered by sigfuz by setting low bits of PT_NIP in the signal context. Fix this for now by masking the SRR0 bits as well. Cleaner is probably to sanitise these values before putting them in registers or stack, but this is the quick and backportable fix. Fixes: 314f6c23dd8d ("powerpc/64s: Mask NIP before checking against SRR0") Signed-off-by: Nicholas Piggin <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-01-17remoteproc: qcom: q6v5: fix service routines build errorsRandy Dunlap2-0/+5
When CONFIG_QCOM_AOSS_QMP=m and CONFIG_QCOM_Q6V5_MSS=y, the builtin driver cannot call into the loadable module's low-level service functions. Trying to build with that config combo causes linker errors. There are two problems here. First, drivers/remoteproc/qcom_q6v5.c should #include <linux/soc/qcom/qcom_aoss.h> for the definitions of the service functions, depending on whether CONFIG_QCOM_AOSS_QMP is set/enabled or not. Second, the qcom remoteproc drivers should depend on QCOM_AOSS_QMP iff it is enabled (=y or =m) so that the qcom remoteproc drivers can be built properly. This prevents these build errors: aarch64-linux-ld: drivers/remoteproc/qcom_q6v5.o: in function `q6v5_load_state_toggle': qcom_q6v5.c:(.text+0xc4): undefined reference to `qmp_send' aarch64-linux-ld: drivers/remoteproc/qcom_q6v5.o: in function `qcom_q6v5_deinit': (.text+0x2e4): undefined reference to `qmp_put' aarch64-linux-ld: drivers/remoteproc/qcom_q6v5.o: in function `qcom_q6v5_init': (.text+0x778): undefined reference to `qmp_get' aarch64-linux-ld: (.text+0x7d8): undefined reference to `qmp_put' Fixes: c1fe10d238c0 ("remoteproc: qcom: q6v5: Use qmp_send to update co-processor load state") Signed-off-by: Randy Dunlap <[email protected]> Reported-by: kernel test robot <[email protected]> Cc: Bjorn Andersson <[email protected]> Cc: Mathieu Poirier <[email protected]> Cc: [email protected] Cc: Sibi Sankar <[email protected]> Cc: Stephen Boyd <[email protected]> Reviewed-by: Stephen Boyd <[email protected]> Reviewed-by: Bjorn Andersson <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-01-17rpmsg: char: Fix race between the release of rpmsg_eptdev and cdevMatthias Kaehlcke1-9/+2
struct rpmsg_eptdev contains a struct cdev. The current code frees the rpmsg_eptdev struct in rpmsg_eptdev_destroy(), but the cdev is a managed object, therefore its release is not predictable and the rpmsg_eptdev could be freed before the cdev is entirely released. The cdev_device_add/del() API was created to address this issue (see commit '233ed09d7fda ("chardev: add helper function to register char devs with a struct device")'), use it instead of cdev add/del(). Fixes: c0cdc19f84a4 ("rpmsg: Driver for user space endpoint interface") Suggested-by: Bjorn Andersson <[email protected]> Signed-off-by: Matthias Kaehlcke <[email protected]> Reviewed-by: Mathieu Poirier <[email protected]> Reviewed-by: Stephen Boyd <[email protected]> Reviewed-by: Bjorn Andersson <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/20220110104706.v6.2.Idde68b05b88d4a2e6e54766c653f3a6d9e419ce6@changeid
2022-01-17rpmsg: char: Fix race between the release of rpmsg_ctrldev and cdevSujit Kautkar1-9/+2
struct rpmsg_ctrldev contains a struct cdev. The current code frees the rpmsg_ctrldev struct in rpmsg_ctrldev_release_device(), but the cdev is a managed object, therefore its release is not predictable and the rpmsg_ctrldev could be freed before the cdev is entirely released, as in the backtrace below. [ 93.625603] ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x7c [ 93.636115] WARNING: CPU: 0 PID: 12 at lib/debugobjects.c:488 debug_print_object+0x13c/0x1b0 [ 93.644799] Modules linked in: veth xt_cgroup xt_MASQUERADE rfcomm algif_hash algif_skcipher af_alg uinput ip6table_nat fuse uvcvideo videobuf2_vmalloc venus_enc venus_dec videobuf2_dma_contig hci_uart btandroid btqca snd_soc_rt5682_i2c bluetooth qcom_spmi_temp_alarm snd_soc_rt5682v [ 93.715175] CPU: 0 PID: 12 Comm: kworker/0:1 Tainted: G B 5.4.163-lockdep #26 [ 93.723855] Hardware name: Google Lazor (rev3 - 8) with LTE (DT) [ 93.730055] Workqueue: events kobject_delayed_cleanup [ 93.735271] pstate: 60c00009 (nZCv daif +PAN +UAO) [ 93.740216] pc : debug_print_object+0x13c/0x1b0 [ 93.744890] lr : debug_print_object+0x13c/0x1b0 [ 93.749555] sp : ffffffacf5bc7940 [ 93.752978] x29: ffffffacf5bc7940 x28: dfffffd000000000 [ 93.758448] x27: ffffffacdb11a800 x26: dfffffd000000000 [ 93.763916] x25: ffffffd0734f856c x24: dfffffd000000000 [ 93.769389] x23: 0000000000000000 x22: ffffffd0733c35b0 [ 93.774860] x21: ffffffd0751994a0 x20: ffffffd075ec27c0 [ 93.780338] x19: ffffffd075199100 x18: 00000000000276e0 [ 93.785814] x17: 0000000000000000 x16: dfffffd000000000 [ 93.791291] x15: ffffffffffffffff x14: 6e6968207473696c [ 93.796768] x13: 0000000000000000 x12: ffffffd075e2b000 [ 93.802244] x11: 0000000000000001 x10: 0000000000000000 [ 93.807723] x9 : d13400dff1921900 x8 : d13400dff1921900 [ 93.813200] x7 : 0000000000000000 x6 : 0000000000000000 [ 93.818676] x5 : 0000000000000080 x4 : 0000000000000000 [ 93.824152] x3 : ffffffd0732a0fa4 x2 : 0000000000000001 [ 93.829628] x1 : ffffffacf5bc7580 x0 : 0000000000000061 [ 93.835104] Call trace: [ 93.837644] debug_print_object+0x13c/0x1b0 [ 93.841963] __debug_check_no_obj_freed+0x25c/0x3c0 [ 93.846987] debug_check_no_obj_freed+0x18/0x20 [ 93.851669] slab_free_freelist_hook+0xbc/0x1e4 [ 93.856346] kfree+0xfc/0x2f4 [ 93.859416] rpmsg_ctrldev_release_device+0x78/0xb8 [ 93.864445] device_release+0x84/0x168 [ 93.868310] kobject_cleanup+0x12c/0x298 [ 93.872356] kobject_delayed_cleanup+0x10/0x18 [ 93.876948] process_one_work+0x578/0x92c [ 93.881086] worker_thread+0x804/0xcf8 [ 93.884963] kthread+0x2a8/0x314 [ 93.888303] ret_from_fork+0x10/0x18 The cdev_device_add/del() API was created to address this issue (see commit '233ed09d7fda ("chardev: add helper function to register char devs with a struct device")'), use it instead of cdev add/del(). Fixes: c0cdc19f84a4 ("rpmsg: Driver for user space endpoint interface") Signed-off-by: Sujit Kautkar <[email protected]> Signed-off-by: Matthias Kaehlcke <[email protected]> Reviewed-by: Mathieu Poirier <[email protected]> Reviewed-by: Bjorn Andersson <[email protected]> Reviewed-by: Stephen Boyd <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/20220110104706.v6.1.Iaac908f3e3149a89190ce006ba166e2d3fd247a3@changeid
2022-01-17scripts/dtc: dtx_diff: remove broken example from help textMatthias Schiffer1-6/+2
dtx_diff suggests to use <(...) syntax to pipe two inputs into it, but this has never worked: The /proc/self/fds/... paths passed by the shell will fail the `[ -f "${dtx}" ] && [ -r "${dtx}" ]` check in compile_to_dts, but even with this check removed, the function cannot work: hexdump will eat up the DTB magic, making the subsequent dtc call fail, as a pipe cannot be rewound. Simply remove this broken example, as there is already an alternative one that works fine. Fixes: 10eadc253ddf ("dtc: create tool to diff device trees") Signed-off-by: Matthias Schiffer <[email protected]> Reviewed-by: Frank Rowand <[email protected]> Signed-off-by: Rob Herring <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-01-17dt-bindings: trivial-devices: fix double spaces in commentsStanislav Jakubek1-3/+3
Cleanup double spaces in some of the comments. Signed-off-by: Stanislav Jakubek <[email protected]> Signed-off-by: Rob Herring <[email protected]> Link: https://lore.kernel.org/r/13b3f66efd3b20f1d9bbb9eff1eca00757ac5367.1642080090.git.stano.jakubek@gmail.com
2022-01-17dt-bindings: trivial-devices: fix swapped commentsStanislav Jakubek1-2/+2
sparkfun,qwiic-joystick and st,24c256 had their comments incorrectly swapped. Swap them to make them correct. Signed-off-by: Stanislav Jakubek <[email protected]> Signed-off-by: Rob Herring <[email protected]> Link: https://lore.kernel.org/r/7dc6ddb0b042cd243b2875e9aea81cad541d1c6b.1642080090.git.stano.jakubek@gmail.com
2022-01-17dt-bindings: vendor-prefixes: add WingtechStanislav Jakubek1-0/+2
The vendor prefix for Wingtech [1] is used in device tree [2], but was not documented so far. Add it to the schema to document it. [1] http://www.wingtech.com/en [2] arch/arm64/boot/dts/qcom/msm8916-wingtech-wt88047.dts Signed-off-by: Stanislav Jakubek <[email protected]> Signed-off-by: Rob Herring <[email protected]> Link: https://lore.kernel.org/r/20220113103110.GA4488@standask-GA-A55M-S2HP
2022-01-17dt-bindings: vendor-prefixes: add ThundercommStanislav Jakubek1-0/+2
The vendor prefix for Thundercomm [1] is used in device tree [2], but was not documented so far. Add it to the schema to document it. [1] https://www.thundercomm.com/ [2] arch/arm64/boot/dts/qcom/sdm845-db845c.dts Signed-off-by: Stanislav Jakubek <[email protected]> Signed-off-by: Rob Herring <[email protected]> Link: https://lore.kernel.org/r/20220113103036.GA4456@standask-GA-A55M-S2HP
2022-01-17dt-bindings: vendor-prefixes: add HuaweiStanislav Jakubek1-0/+2
The vendor prefix for Huawei [1] is used in device trees [2][3], but was not documented so far. Add it to the schema to document it. [1] https://www.huawei.com/en/ [2] arch/arm64/boot/dts/qcom/msm8916-huawei-g7.dts [3] arch/arm64/boot/dts/qcom/msm8994-angler-rev-101.dts Signed-off-by: Stanislav Jakubek <[email protected]> Signed-off-by: Rob Herring <[email protected]> Link: https://lore.kernel.org/r/20220113103005.GA4421@standask-GA-A55M-S2HP
2022-01-17dt-bindings: vendor-prefixes: add F(x)tecStanislav Jakubek1-0/+2
The vendor prefix for F(x)tec [1] is used in device tree [2], but was not documented so far. Add it to the schema to document it. [1] https://www.fxtec.com/ [2] arch/arm64/boot/dts/qcom/msm8998-fxtec-pro1.dts Signed-off-by: Stanislav Jakubek <[email protected]> Signed-off-by: Rob Herring <[email protected]> Link: https://lore.kernel.org/r/20220113102926.GA4388@standask-GA-A55M-S2HP
Powered by cgit, Gruvboxed by Blaster4385.