Select Git revision
Search by author
- Any Author
- authors
-
Alessandro Pecugi alessandro.pecugi
-
Andrea Da Col
andrea.dacol
-
Andrii Sosiuk
andrii.sosiuk
-
Carlo Ferriolo carlo.ferriolo
-
Christian Stimming
christian.stimming
-
Christos Karampeazis
-
CI Variables Management Service Account service_account_ci_vars_management
-
Costanza Vasai costanza.vasai
-
Daniel Rinaldi daniel.rinaldi
-
Davide Cardillo
davide.cardillo
-
Dietmar Muscholik dietmar.muscholik
-
Dmitry Petrov dmitry.petrov
-
Elias Radi elias.radi
-
Ettore Chimenti
ektor5
-
Fabio Falsini
fabio.falsini
-
Fabrizio Benvenuti fabrizio.benvenuti
-
Felix Gerking felix.gerking
-
Gianfranco Mariotti
gianfranco.mariotti
-
GitBot
gitbot
-
Git Bot Service Account
service_account_gitbot
- May 14, 2021
-
-
Qinglang Miao authored
[ Upstream commit 47ff6172 ] In i2c_imx_xfer() and i2c_imx_remove(), the pm reference count is not expected to be incremented on return. However, pm_runtime_get_sync will increment pm reference count even failed. Forgetting to putting operation will result in a reference leak here. Replace it with pm_runtime_resume_and_get to keep usage counter balanced. Fixes: 3a5ee18d ("i2c: imx: implement master_xfer_atomic callback") Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Qinglang Miao <miaoqinglang@huawei.com> Reviewed-by:
Oleksij Rempel <o.rempel@pengutronix.de> Signed-off-by:
Wolfram Sang <wsa@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Qinglang Miao authored
[ Upstream commit 278e5bbd ] The PM reference count is not expected to be incremented on return in lpi2c_imx_master_enable. However, pm_runtime_get_sync will increment the PM reference count even failed. Forgetting to putting operation will result in a reference leak here. Replace it with pm_runtime_resume_and_get to keep usage counter balanced. Fixes: 13d6eb20 ("i2c: imx-lpi2c: add runtime pm support") Reported-by:
-
Qinglang Miao authored
[ Upstream commit 223125e3 ] The PM reference count is not expected to be incremented on return in functions img_i2c_xfer and img_i2c_init. However, pm_runtime_get_sync will increment the PM reference count even failed. Forgetting to putting operation will result in a reference leak here. Replace it with pm_runtime_resume_and_get to keep usage counter balanced. Fixes: 93222bd9 ("i2c: img-scb: Add runtime PM") Reported-by:
-
Qinglang Miao authored
[ Upstream commit 23ceb846 ] The PM reference count is not expected to be incremented on return in functions cdns_i2c_master_xfer and cdns_reg_slave. However, pm_runtime_get_sync will increment pm usage counter even failed. Forgetting to putting operation will result in a reference leak here. Replace it with pm_runtime_resume_and_get to keep usage counter balanced. Fixes: 7fa32329 ("i2c: cadence: Move to sensible power management") Reported-by:
-
Gioh Kim authored
[ Upstream commit 7f4a8592 ] A session can be removed dynamically by sysfs interface "remove_path" that eventually calls rtrs_clt_remove_path_from_sysfs function. The current rtrs_clt_remove_path_from_sysfs first removes the sysfs interfaces and frees sess->stats object. Second it removes the session from the active list. Therefore some functions could access non-connected session and access the freed sess->stats object even-if they check the session status before accessing the session. For instance rtrs_clt_request and get_next_path_min_inflight check the session status and try to send IO to the session. The session status could be changed when they are trying to send IO but they could not catch the change and update the statistics information in sess->stats object, and generate use-after-free problem. (see: "RDMA/rtrs-clt: Check state of the rtrs_clt_sess before reading its stats") This patch changes the rtrs_clt_remove_path_from_sysfs to remove the session from the active session list and then destroy the sysfs interfaces. Each function still should check the session status because closing or error recovery paths can change the status. Fixes: 6a98d71d ("RDMA/rtrs: client: main functionality") Link: https://lore.kernel.org/r/20210412084002.33582-1-gi-oh.kim@ionos.com Signed-off-by:
Gioh Kim <gi-oh.kim@ionos.com> Reviewed-by:
Jack Wang <jinpu.wang@ionos.com> Signed-off-by:
Jason Gunthorpe <jgg@nvidia.com> Signed-off-by:
-
Wang Wensheng authored
[ Upstream commit 6bc950be ] Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Fixes: db7683d7 ("IB/srpt: Fix login-related race conditions") Link: https://lore.kernel.org/r/20210408113132.87250-1-wangwensheng4@huawei.com Reported-by:
Wang Wensheng <wangwensheng4@huawei.com> Reviewed-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
-
Colin Ian King authored
[ Upstream commit e701a258 ] The shifting of the u8 integers rq->caching by 26 bits to the left will be promoted to a 32 bit signed int and then sign-extended to a u64. In the event that rq->caching is greater than 0x1f then all then all the upper 32 bits of the u64 end up as also being set because of the int sign-extension. Fix this by casting the u8 values to a u64 before the 26 bit left shift. Addresses-Coverity: ("Unintended sign extension") Fixes: 4863dea3 ("net: Adding support for Cavium ThunderX network controller") Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Colin Ian King authored
[ Upstream commit dd2c7967 ] The shifting of the u8 integers f->fs.nat_lip[] by 24 bits to the left will be promoted to a 32 bit signed int and then sign-extended to a u64. In the event that the top bit of the u8 is set then all then all the upper 32 bits of the u64 end up as also being set because of the sign-extension. Fix this by casting the u8 values to a u64 before the 24 bit left shift. Addresses-Coverity: ("Unintended sign extension") Fixes: 12b276fb ("cxgb4: add support to create hash filters") Signed-off-by:
-
Wang Wensheng authored
[ Upstream commit 22efb0a8 ] Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Fixes: 1ac5a404 ("RDMA/bnxt_re: Add bnxt_re RoCE driver") Link: https://lore.kernel.org/r/20210408113137.97202-1-wangwensheng4@huawei.com Reported-by:
-
Wang Wensheng authored
[ Upstream commit 4c7d9c69 ] Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Fixes: 77241056 ("IB/hfi1: add driver files") Link: https://lore.kernel.org/r/20210408113140.103032-1-wangwensheng4@huawei.com Reported-by:
-
Wang Wensheng authored
[ Upstream commit 10dd83db ] Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Fixes: 82af6d19 ("RDMA/qedr: Fix synchronization methods and memory leaks in qedr") Link: https://lore.kernel.org/r/20210408113135.92165-1-wangwensheng4@huawei.com Reported-by:
Michal <Kalderon <michal.kalderon@marvell.com> Signed-off-by:
-
Amir Goldstein authored
[ Upstream commit 65cd913e ] The test in ovl_dentry_version_inc() was out-dated and did not include the case where readdir cache is used on a non-merge dir that has origin xattr, indicating that it may contain leftover whiteouts. To make the code more robust, use the same helper ovl_dir_is_real() to determine if readdir cache should be used and if readdir cache should be invalidated. Fixes: b79e05aa ("ovl: no direct iteration for dir with origin xattr") Link: https://lore.kernel.org/linux-unionfs/CAOQ4uxht70nODhNHNwGFMSqDyOKLXOKrY0H6g849os4BQ7cokA@mail.gmail.com/ Cc: Chris Murphy <lists@colorremedies.com> Signed-off-by:
Amir Goldstein <amir73il@gmail.com> Signed-off-by:
Miklos Szeredi <mszeredi@redhat.com> Signed-off-by:
-
Nicholas Piggin authored
[ Upstream commit 5088eb40 ] The host CTRL (runlatch) value is not restored after guest exit. The host CTRL should always be 1 except in CPU idle code, so this can result in the host running with runlatch clear, and potentially switching to a different vCPU which then runs with runlatch clear as well. This has little effect on P9 machines, CTRL is only responsible for some PMU counter logic in the host and so other than corner cases of software relying on that, or explicitly reading the runlatch value (Linux does not appear to be affected but it's possible non-Linux guests could be), there should be no execution correctness problem, though it could be used as a covert channel between guests. There may be microcontrollers, firmware or monitoring tools that sample the runlatch value out-of-band, however since the register is writable by guests, these values would (should) not be relied upon for correct operation of the host, so suboptimal performance or incorrect reporting should be the worst problem. Fixes: 95a6432c ("KVM: PPC: Book3S HV: Streamlined guest entry/exit path on P9 for radix guests") Signed-off-by:
Nicholas Piggin <npiggin@gmail.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20210412014845.1517916-2-npiggin@gmail.com Signed-off-by:
-
Sean Wang authored
[ Upstream commit 45247a85 ] Use the additional memory barrier to ensure the skb list up-to-date between the skb producer and consumer to avoid the invalid skb content written into sdio controller and then cause device hang due to mcu assert caught by WR_TIMEOUT_INT. Fixes: 1522ff73 ("mt76: mt7663s: introduce sdio tx aggregation") Signed-off-by:
Sean Wang <sean.wang@mediatek.com> Signed-off-by:
Felix Fietkau <nbd@nbd.name> Signed-off-by:
-
Sean Wang authored
[ Upstream commit 455ae5aa ] Each packet should be padded with the additional zero to become 4-bytes alignment in sdio tx aggregation. Fixes: 1522ff73 ("mt76: mt7663s: introduce sdio tx aggregation") Signed-off-by:
-
Ryder Lee authored
[ Upstream commit 2b35050a ] In order to properly report MIB counters to mac80211, resets stats in mt7915_get_stats routine() and hold mt76 mutex accessing MIB counters. Sum up MIB counters in mt7915_mac_update_mib_stats routine. Fixes: e57b7901 ("mt76: add mac80211 driver for MT7915 PCIe-based chipsets") Signed-off-by:
Ryder Lee <ryder.lee@mediatek.com> Signed-off-by:
-
Lorenzo Bianconi authored
[ Upstream commit 2eb6f6c4 ] In order to properly report MIB counters to mac80211, resets stats in mt7615_get_stats routine and hold mt76 mutex accessing MIB counters. Sum up MIB counters in mt7615_mac_update_mib_stats routine. Fixes: c388d858 ("mt76: mt7615: add a get_stats() callback") Signed-off-by:
Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by:
-
Lorenzo Bianconi authored
[ Upstream commit 9fb9d755 ] Similar to mt7921, fix 802.11 aggr len debugfs reporting for mt7915 driver. Fixes: e57b7901 ("mt76: add mac80211 driver for MT7915 PCIe-based chipsets") Signed-off-by:
-
Felix Fietkau authored
[ Upstream commit 7dcf3c04 ] The first pointer in the txp needs to be unmapped as well, otherwise it will leak DMA mapping entries Reported-by:
Ben Greear <greearb@candelatech.com> Fixes: 27d5c528 ("mt76: fix double DMA unmap of the first buffer on 7615/7915") Signed-off-by:
-
Felix Fietkau authored
[ Upstream commit ebee7885 ] The first pointer in the txp needs to be unmapped as well, otherwise it will leak DMA mapping entries Fixes: 27d5c528 ("mt76: fix double DMA unmap of the first buffer on 7615/7915") Signed-off-by:
-
Colin Ian King authored
[ Upstream commit 87fce886 ] Currently the expression ~nic_conf1 is always true because nic_conf1 is a u16 and according to 6.5.3.3 of the C standard the ~ operator promotes the u16 to an integer before flipping all the bits. Thus the top 16 bits of the integer result are all set so the expression is always true. If the intention was to flip all the bits of nic_conf1 then casting the integer result back to a u16 is a suitabel fix. Interestingly static analyzers seem to thing a bitwise ! should be used instead of ~ for this scenario, so I think the original intent of the expression may need some extra consideration. Addresses-Coverity: ("Logical vs. bitwise operator") Fixes: c869f77d ("add mt7601u driver") Signed-off-by:
Jakub Kicinski <kubakici@wp.pl> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210225183241.1002129-1-colin.king@canonical.com Signed-off-by:
-
Dan Carpenter authored
[ Upstream commit c9eaee0c ] The sscanf() function returns the number of matches (0 or 1 in this case). It doesn't return error codes. We should return -EINVAL if the string is invalid Fixes: c376c1fc ("rtw88: add h2c command in debugfs") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Colin Ian King authored
[ Upstream commit 3b6dd9a9aeeada19d0c820ff68e979243a888bb6 ] A previous commit removed a call to xfs_attr3_leaf_read that assigned an error return code to variable error. We now have a few early error return paths to label 'out' that return error if error is set; however error now is uninitialized so potentially garbage is being returned. Fix this by setting error to zero to restore the original behaviour where error was zero at the label 'restart'. Addresses-Coverity: ("Uninitialized scalar variable") Fixes: 07120f1a ("xfs: Add xfs_has_attr and subroutines") Signed-off-by:Brian Foster <bfoster@redhat.com> Reviewed-by:
Darrick J. Wong <djwong@kernel.org> Signed-off-by:
-
Smita Koralahalli authored
[ Upstream commit 86c2bc3d ] Commit 08ed77e4 ("perf vendor events amd: Add recommended events") added the hits event "L2 Cache Hits from L2 HWPF" with the same metric expression as the accesses event "L2 Cache Accesses from L2 HWPF": $ perf list --details ... l2_cache_accesses_from_l2_hwpf [L2 Cache Accesses from L2 HWPF] [l2_pf_hit_l2 + l2_pf_miss_l2_hit_l3 + l2_pf_miss_l2_l3] l2_cache_hits_from_l2_hwpf [L2 Cache Hits from L2 HWPF] [l2_pf_hit_l2 + l2_pf_miss_l2_hit_l3 + l2_pf_miss_l2_l3] ... This was wrong and led to counting hits the same as accesses. Section 2.1.15.2 "Performance Measurement" of "PPR for AMD Family 17h Model 31h B0 - 55803 Rev 0.54 - Sep 12, 2019", documents the hits event with EventCode 0x70 which is the same as l2_pf_hit_l2. Fix this, and massage the description for l2_pf_hit_l2 as the hits event is now the duplicate of l2_pf_hit_l2. AMD recommends using the recommended event over other events if the duplicate exists and maintain both for consistency. Hence, l2_cache_hits_from_l2_hwpf should override l2_pf_hit_l2. Before: # perf stat -M l2_cache_accesses_from_l2_hwpf,l2_cache_hits_from_l2_hwpf sleep 1 Performance counter stats for 'sleep 1': 1,436 l2_pf_miss_l2_l3 # 11114.00 l2_cache_accesses_from_l2_hwpf # 11114.00 l2_cache_hits_from_l2_hwpf 4,482 l2_pf_hit_l2 5,196 l2_pf_miss_l2_hit_l3 1.001765339 seconds time elapsed After: # perf stat -M l2_cache_accesses_from_l2_hwpf sleep 1 Performance counter stats for 'sleep 1': 1,477 l2_pf_miss_l2_l3 # 10442.00 l2_cache_accesses_from_l2_hwpf 3,978 l2_pf_hit_l2 4,987 l2_pf_miss_l2_hit_l3 1.001491186 seconds time elapsed # perf stat -e l2_cache_hits_from_l2_hwpf sleep 1 Performance counter stats for 'sleep 1': 3,983 l2_cache_hits_from_l2_hwpf 1.001329970 seconds time elapsed Note the difference in performance counter values for the accesses versus the hits after the fix, and the hits event now counting the same as l2_pf_hit_l2. Fixes: 08ed77e4 ("perf vendor events amd: Add recommended events") Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=206537 Reviewed-by:
Robert Richter <rrichter@amd.com> Signed-off-by:
Smita Koralahalli <Smita.KoralahalliChannabasappa@amd.com> Tested-by: Arnaldo Carvalho de Melo <acme@kernel.org> # On a 3900X Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Ian Rogers <irogers@google.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Kim Phillips <kim.phillips@amd.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Martin Liška <mliska@suse.cz> Cc: Michael Petlan <mpetlan@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Vijay Thakkar <vijaythakkar@me.com> Cc: linux-perf-users@vger.kernel.org Link: https://lore.kernel.org/r/20210406215944.113332-2-Smita.KoralahalliChannabasappa@amd.com Signed-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
-
Johannes Berg authored
[ Upstream commit db878e27 ] If any of the cipher schemes specified by the driver are invalid, bail out and fail the registration rather than just warning. Otherwise, we might later crash when we try to use the invalid cipher scheme, e.g. if the hdr_len is (significantly) less than the pn_offs + pn_len, we'd have an out-of-bounds access in RX validation. Fixes: 2475b1cc ("mac80211: add generic cipher scheme support") Link: https://lore.kernel.org/r/20210408143149.38a3a13a1b19.I6b7f5790fa0958ed8049cf02ac2a535c61e9bc96@changeid Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Randy Dunlap authored
[ Upstream commit b27dadec ] When neither CONFIG_PCI nor CONFIG_IBMVIO is set/enabled, iommu.c has a build error. The fault injection code is not useful in that kernel config, so make the FAIL_IOMMU option depend on PCI || IBMVIO. Prevents this build error (warning escalated to error): ../arch/powerpc/kernel/iommu.c:178:30: error: 'fail_iommu_bus_notifier' defined but not used [-Werror=unused-variable] 178 | static struct notifier_block fail_iommu_bus_notifier = { Fixes: d6b9a81b ("powerpc: IOMMU fault injection") Reported-by:
kernel test robot <lkp@intel.com> Suggested-by:
Randy Dunlap <rdunlap@infradead.org> Acked-by: Randy Dunlap <rdunlap@infradead.org> # build-tested Signed-off-by:
-
Athira Rajeev authored
[ Upstream commit 10f8f961 ] The power PMU group constraints includes check for EBB events to make sure all events in a group must agree on EBB. This will prevent scheduling EBB and non-EBB events together. But in the existing check, settings for constraint mask and value is interchanged. Patch fixes the same. Before the patch, PMU selftest "cpu_event_pinned_vs_ebb_test" fails with below in dmesg logs. This happens because EBB event gets enabled along with a non-EBB cpu event. [35600.453346] cpu_event_pinne[41326]: illegal instruction (4) at 10004a18 nip 10004a18 lr 100049f8 code 1 in cpu_event_pinned_vs_ebb_test[10000000+10000] Test results after the patch: $ ./pmu/ebb/cpu_event_pinned_vs_ebb_test test: cpu_event_pinned_vs_ebb tags: git_version:v5.12-rc5-93-gf28c3125acd3-dirty Binding to cpu 8 EBB Handler is at 0x100050c8 read error on event 0x7fffe6bd4040! PM_RUN_INST_CMPL: result 9872 running/enabled 37930432 success: cpu_event_pinned_vs_ebb This bug was hidden by other logic until commit 1908dc91 (perf: Tweak perf_event_attr::exclusive semantics). Fixes: 4df48999 ("powerpc/perf: Add power8 EBB support") Reported-by:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Signed-off-by:
Athira Rajeev <atrajeev@linux.vnet.ibm.com> [mpe: Mention commit 1908dc91] Signed-off-by:
-
Jordan Niethe authored
[ Upstream commit b8b2f37c ] When adding a PTE a ptesync is needed to order the update of the PTE with subsequent accesses otherwise a spurious fault may be raised. radix__set_pte_at() does not do this for performance gains. For non-kernel memory this is not an issue as any faults of this kind are corrected by the page fault handler. For kernel memory these faults are not handled. The current solution is that there is a ptesync in flush_cache_vmap() which should be called when mapping from the vmalloc region. However, map_kernel_page() does not call flush_cache_vmap(). This is troublesome in particular for code patching with Strict RWX on radix. In do_patch_instruction() the page frame that contains the instruction to be patched is mapped and then immediately patched. With no ordering or synchronization between setting up the PTE and writing to the page it is possible for faults. As the code patching is done using __put_user_asm_goto() the resulting fault is obscured - but using a normal store instead it can be seen: BUG: Unable to handle kernel data access on write at 0xc008000008f24a3c Faulting instruction address: 0xc00000000008bd74 Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA PowerNV Modules linked in: nop_module(PO+) [last unloaded: nop_module] CPU: 4 PID: 757 Comm: sh Tainted: P O 5.10.0-rc5-01361-ge3c1b78c8440-dirty #43 NIP: c00000000008bd74 LR: c00000000008bd50 CTR: c000000000025810 REGS: c000000016f634a0 TRAP: 0300 Tainted: P O (5.10.0-rc5-01361-ge3c1b78c8440-dirty) MSR: 9000000000009033 <SF,HV,EE,ME,IR,DR,RI,LE> CR: 44002884 XER: 00000000 CFAR: c00000000007c68c DAR: c008000008f24a3c DSISR: 42000000 IRQMASK: 1 This results in the kind of issue reported here: https://lore.kernel.org/linuxppc-dev/15AC5B0E-A221-4B8C-9039-FA96B8EF7C88@lca.pw/ Chris Riedl suggested a reliable way to reproduce the issue: $ mount -t debugfs none /sys/kernel/debug $ (while true; do echo function > /sys/kernel/debug/tracing/current_tracer ; echo nop > /sys/kernel/debug/tracing/current_tracer ; done) & Turning ftrace on and off does a large amount of code patching which in usually less then 5min will crash giving a trace like: ftrace-powerpc: (____ptrval____): replaced (4b473b11) != old (60000000) ------------[ ftrace bug ]------------ ftrace failed to modify [<c000000000bf8e5c>] napi_busy_loop+0xc/0x390 actual: 11:3b:47:4b Setting ftrace call site to call ftrace function ftrace record flags: 80000001 (1) expected tramp: c00000000006c96c ------------[ cut here ]------------ WARNING: CPU: 4 PID: 809 at kernel/trace/ftrace.c:2065 ftrace_bug+0x28c/0x2e8 Modules linked in: nop_module(PO-) [last unloaded: nop_module] CPU: 4 PID: 809 Comm: sh Tainted: P O 5.10.0-rc5-01360-gf878ccaf250a #1 NIP: c00000000024f334 LR: c00000000024f330 CTR: c0000000001a5af0 REGS: c000000004c8b760 TRAP: 0700 Tainted: P O (5.10.0-rc5-01360-gf878ccaf250a) MSR: 900000000282b033 <SF,HV,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 28008848 XER: 20040000 CFAR: c0000000001a9c98 IRQMASK: 0 GPR00: c00000000024f330 c000000004c8b9f0 c000000002770600 0000000000000022 GPR04: 00000000ffff7fff c000000004c8b6d0 0000000000000027 c0000007fe9bcdd8 GPR08: 0000000000000023 ffffffffffffffd8 0000000000000027 c000000002613118 GPR12: 0000000000008000 c0000007fffdca00 0000000000000000 0000000000000000 GPR16: 0000000023ec37c5 0000000000000000 0000000000000000 0000000000000008 GPR20: c000000004c8bc90 c0000000027a2d20 c000000004c8bcd0 c000000002612fe8 GPR24: 0000000000000038 0000000000000030 0000000000000028 0000000000000020 GPR28: c000000000ff1b68 c000000000bf8e5c c00000000312f700 c000000000fbb9b0 NIP ftrace_bug+0x28c/0x2e8 LR ftrace_bug+0x288/0x2e8 Call Trace: ftrace_bug+0x288/0x2e8 (unreliable) ftrace_modify_all_code+0x168/0x210 arch_ftrace_update_code+0x18/0x30 ftrace_run_update_code+0x44/0xc0 ftrace_startup+0xf8/0x1c0 register_ftrace_function+0x4c/0xc0 function_trace_init+0x80/0xb0 tracing_set_tracer+0x2a4/0x4f0 tracing_set_trace_write+0xd4/0x130 vfs_write+0xf0/0x330 ksys_write+0x84/0x140 system_call_exception+0x14c/0x230 system_call_common+0xf0/0x27c To fix this when updating kernel memory PTEs using ptesync. Fixes: f1cb8f9b ("powerpc/64s/radix: avoid ptesync after set_pte and ptep_set_access_flags") Signed-off-by:
Jordan Niethe <jniethe5@gmail.com> Reviewed-by:
-
Mike Marciniszyn authored
[ Upstream commit ca5f7256 ] The code currently assumes that the mmu_notifier struct embedded in mmu_rb_handler only contains two fields. There are now extra fields: struct mmu_notifier { struct hlist_node hlist; const struct mmu_notifier_ops *ops; struct mm_struct *mm; struct rcu_head rcu; unsigned int users; }; Given that there in no init for the mmu_notifier, a kzalloc() should be used to insure that any newly added fields are given a predictable initial value of zero. Fixes: 06e0ffa6 ("IB/hfi1: Re-factor MMU notification code") Link: https://lore.kernel.org/r/1617026056-50483-9-git-send-email-dennis.dalessandro@cornelisnetworks.com Reviewed-by:
Adam Goldman <adam.goldman@intel.com> Signed-off-by:
Mike Marciniszyn <mike.marciniszyn@cornelisnetworks.com> Signed-off-by:
Dennis Dalessandro <dennis.dalessandro@cornelisnetworks.com> Signed-off-by:
-
Colin Ian King authored
[ Upstream commit 298b58f0 ] The macro CN23XX_PEM_BAR1_INDEX_REG is being used to shift oct->pcie_port (a u16) left 24 places. There are two subtle issues here, first the shift gets promoted to an signed int and then sign extended to a u64. If oct->pcie_port is 0x80 or more then the upper bits get sign extended to 1. Secondly shfiting a u16 24 bits will lead to an overflow so it needs to be cast to a u64 for all the bits to not overflow. It is entirely possible that the u16 port value is never large enough for this to fail, but it is useful to fix unintended overflows such as this. Fix this by casting the port parameter to the macro to a u64 before the shift. Addresses-Coverity: ("Unintended sign extension") Fixes: 5bc67f58 ("liquidio: CN23XX register definitions") Signed-off-by:
-
Krzysztof Kozlowski authored
[ Upstream commit fa74c223 ] The 'single_cpu' local variable is assigned by asoc_simple_parse_dai() and later used in a asoc_simple_canonicalize_cpu() call, assuming the entire function did not exit on errors. However the first function returns 0 if passed device_node is NULL, thus leaving the variable uninitialized and reporting success. Addresses-Coverity: Uninitialized scalar variable Fixes: 8f7f298a ("ASoC: simple-card-utils: separate asoc_simple_card_parse_dai()") Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Acked-by:
Sameer Pujar <spujar@nvidia.com> Link: https://lore.kernel.org/r/20210407092027.60769-1-krzysztof.kozlowski@canonical.com Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Alexandru Elisei authored
[ Upstream commit 263d6287 ] When a VCPU is created, the kvm_vcpu struct is initialized to zero in kvm_vm_ioctl_create_vcpu(). On VHE systems, the first time vcpu.arch.mdcr_el2 is loaded on hardware is in vcpu_load(), before it is set to a sensible value in kvm_arm_setup_debug() later in the run loop. The result is that KVM executes for a short time with MDCR_EL2 set to zero. This has several unintended consequences: * Setting MDCR_EL2.HPMN to 0 is constrained unpredictable according to ARM DDI 0487G.a, page D13-3820. The behavior specified by the architecture in this case is for the PE to behave as if MDCR_EL2.HPMN is set to a value less than or equal to PMCR_EL0.N, which means that an unknown number of counters are now disabled by MDCR_EL2.HPME, which is zero. * The host configuration for the other debug features controlled by MDCR_EL2 is temporarily lost. This has been harmless so far, as Linux doesn't use the other fields, but that might change in the future. Let's avoid both issues by initializing the VCPU's mdcr_el2 field in kvm_vcpu_vcpu_first_run_init(), thus making sure that the MDCR_EL2 register has a consistent value after each vcpu_load(). Fixes: d5a21bcc ("KVM: arm64: Move common VHE/non-VHE trap config in separate functions") Signed-off-by:
Alexandru Elisei <alexandru.elisei@arm.com> Signed-off-by:
Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20210407144857.199746-3-alexandru.elisei@arm.com Signed-off-by:
-
Hans de Goede authored
[ Upstream commit 61710324 ] Mapping the mic-mute button to KEY_MICMUTE is technically correct but KEY_MICMUTE translates to a scancode of 256 (248 + 8) under X, which does not fit in 8 bits, so it does not work. Because of this userspace is expecting KEY_F20 instead, theoretically KEY_MICMUTE should work under Wayland but even there it does not work, because the desktop-environment is listening only for KEY_F20 and not for KEY_MICMUTE. Fixes: bc04b37e ("HID: lenovo: Add ThinkPad 10 Ultrabook Keyboard support") Reviewed-by:
Marek Behún <kabel@kernel.org> Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Hans de Goede authored
[ Upstream commit 34348a86 ] The HID lenovo probe function only attaches drvdata to one of the USB interfaces, but lenovo_event() will get called for all USB interfaces to which hid-lenovo is bound. This allows a malicious device to fake being a device handled by hid-lenovo, which generates events for which lenovo_event() has special handling (and thus dereferences hid_get_drvdata()) on another interface triggering a NULL pointer exception. Add a check for hid_get_drvdata() returning NULL, avoiding this possible NULL pointer exception. Fixes: bc04b37e ("HID: lenovo: Add ThinkPad 10 Ultrabook Keyboard support") Reviewed-by:
-
Hans de Goede authored
[ Upstream commit 658d04e6 ] Fix the following issues with lenovo_led_set_tp10ubkbd() error handling: 1. On success hid_hw_raw_request() returns the number of bytes sent. So we should check for (ret != 3) rather then for (ret != 0). 2. Actually propagate errors to the caller. 3. Since the LEDs are part of an USB keyboard-dock the mute LEDs can go away at any time. Don't log an error when ret == -ENODEV and set the LED_HW_PLUGGABLE flag to avoid errors getting logged when the USB gets disconnected. Fixes: bc04b37e ("HID: lenovo: Add ThinkPad 10 Ultrabook Keyboard support") Reviewed-by:
-
Hans de Goede authored
[ Upstream commit bbf62645 ] The lenovo_led_brightness_set function may sleep, so we should have the the led_class_dev's brightness_set_blocking callback point to it, rather then the regular brightness_set callback. When toggled through sysfs this is not a problem, but the brightness_set callback may be called from atomic context when using LED-triggers. Fixes: bc04b37e ("HID: lenovo: Add ThinkPad 10 Ultrabook Keyboard support") Reviewed-by:
Pavel Machek <pavel@ucw.cz> Signed-off-by:
-
Takashi Iwai authored
[ Upstream commit 5fb45414 ] There are a few calls of usb_driver_claim_interface() but all of those miss the proper error checks, as reported by Coverity. This patch adds those missing checks. Along with it, replace the magic pointer with -1 with a constant USB_AUDIO_IFACE_UNUSED for better readability. Reported-by:
coverity-bot <keescook+coverity-bot@chromium.org> Addresses-Coverity-ID: 1475943 ("Error handling issues") Addresses-Coverity-ID: 1475944 ("Error handling issues") Addresses-Coverity-ID: 1475945 ("Error handling issues") Fixes: b1ce7ba6 ("ALSA: usb-audio: claim autodetected PCM interfaces all at once") Fixes: e5779998 ("ALSA: usb-audio: refactor code") Link: https://lore.kernel.org/r/202104051059.FB7F3016@keescook Link: https://lore.kernel.org/r/20210406113534.30455-1-tiwai@suse.de Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Lu Baolu authored
[ Upstream commit c0474a60 ] When the Intel IOMMU is operating in the scalable mode, some information from the root and context table may be used to tag entries in the PASID cache. Software should invalidate the PASID-cache when changing root or context table entries. Suggested-by:
Ashok Raj <ashok.raj@intel.com> Fixes: 7373a8cc ("iommu/vt-d: Setup context and enable RID2PASID support") Signed-off-by:
Lu Baolu <baolu.lu@linux.intel.com> Link: https://lore.kernel.org/r/20210320025415.641201-4-baolu.lu@linux.intel.com Signed-off-by:
Joerg Roedel <jroedel@suse.de> Signed-off-by:
-
Lu Baolu authored
[ Upstream commit eea53c58 ] When the first level page table is used for IOVA translation, it only supports Read-Only and Read-Write permissions. The Write-Only permission is not supported as the PRESENT bit (implying Read permission) should always set. When using second level, we still give separate permissions that allows WriteOnly which seems inconsistent and awkward. We want to have consistent behavior. After moving to 1st level, we don't want things to work sometimes, and break if we use 2nd level for the same mappings. Hence remove this configuration. Suggested-by:
-
Lu Baolu authored
[ Upstream commit a8ce9ebb ] The Access/Dirty bits in the first level page table entry will be set whenever a page table entry was used for address translation or write permission was successfully translated. This is always true when using the first-level page table for kernel IOVA. Instead of wasting hardware cycles to update the certain bits, it's better to set them up at the beginning. Suggested-by:
-
