Rebase new los21 #3
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- So it supercedes qcom governor and registers teo as the main cpuidle governor. Signed-off-by: Kazuki Hashimoto <kazukih@tuta.io> Signed-off-by: Cyber Knight <cyberknight755@gmail.com>
* Switch to TEO cpuidle governor too. Change-Id: Ia2602444bfddd3e92845fec5a8ba8f2c13e075bf
The busy_factor, which increases load balance interval when a cpu is busy, is set to 32 by default. This value generates some huge LB interval on large system like the THX2 made of 2 node x 28 cores x 4 threads. For such system, the interval increases from 112ms to 3584ms at MC level. And from 228ms to 7168ms at NUMA level. Even on smaller system, a lower busy factor has shown improvement on the fair distribution of the running time so let reduce it for all. Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Phil Auld <pauld@redhat.com> Link: https://lkml.kernel.org/r/20200921072424.14813-5-vincent.guittot@linaro.org Signed-off-by: Zlatan Radovanovic <zlatan.radovanovic@fet.ba> Signed-off-by: Cyber Knight <cyberknight755@gmail.com>
sched domains tend to trigger simultaneously the load balance loop but the larger domains often need more time to collect statistics. This slowness makes the larger domain trying to detach tasks from a rq whereas tasks already migrated somewhere else at a sub-domain level. This is not a real problem for idle LB because the period of smaller domains will increase with its CPUs being busy and this will let time for higher ones to pulled tasks. But this becomes a problem when all CPUs are already busy because all domains stay synced when they trigger their LB. A simple way to minimize simultaneous LB of all domains is to decrement the the busy interval by 1 jiffies. Because of the busy_factor, the interval of larger domain will not be a multiple of smaller ones anymore. Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Phil Auld <pauld@redhat.com> Link: https://lkml.kernel.org/r/20200921072424.14813-4-vincent.guittot@linaro.org Signed-off-by: Zlatan Radovanovic <zlatan.radovanovic@fet.ba> Signed-off-by: Cyber Knight <cyberknight755@gmail.com>
The 25% default imbalance threshold for DIE and NUMA domain is large enough to generate significant unfairness between threads. A typical example is the case of 11 threads running on 2x4 CPUs. The imbalance of 20% between the 2 groups of 4 cores is just low enough to not trigger the load balance between the 2 groups. We will have always the same 6 threads on one group of 4 CPUs and the other 5 threads on the other group of CPUS. With a fair time sharing in each group, we ends up with +20% running time for the group of 5 threads. Consider decreasing the imbalance threshold for overloaded case where we use the load to balance task and to ensure fair time sharing. Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Phil Auld <pauld@redhat.com> Acked-by: Hillf Danton <hdanton@sina.com> Link: https://lkml.kernel.org/r/20200921072424.14813-3-vincent.guittot@linaro.org Signed-off-by: Zlatan Radovanovic <zlatan.radovanovic@fet.ba> Signed-off-by: Cyber Knight <cyberknight755@gmail.com>
When a boosted task gets throttled, what normally happens is that it's immediately enqueued again with ENQUEUE_REPLENISH, which replenishes the runtime and clears the dl_throttled flag. There is a special case however: if the throttling happened on sched-out and the task has been deboosted in the meantime, the replenish is skipped as the task will return to its normal scheduling class. This leaves the task with the dl_throttled flag set. Now if the task gets boosted up to the deadline scheduling class again while it is sleeping, it's still in the throttled state. The normal wakeup however will enqueue the task with ENQUEUE_REPLENISH not set, so we don't actually place it on the rq. Thus we end up with a task that is runnable, but not actually on the rq and neither a immediate replenishment happens, nor is the replenishment timer set up, so the task is stuck in forever-throttled limbo. Clear the dl_throttled flag before dropping back to the normal scheduling class to fix this issue. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Juri Lelli <juri.lelli@redhat.com> Link: https://lkml.kernel.org/r/20200831110719.2126930-1-l.stach@pengutronix.de Signed-off-by: Zlatan Radovanovic <zlatan.radovanovic@fet.ba> Signed-off-by: Cyber Knight <cyberknight755@gmail.com>
This change is for general scheduler improvements. Change-Id: Ia2854ae8701151761fe0780b6451133ab09a050b Signed-off-by: Lingutla Chandrasekhar <clingutla@codeaurora.org> Signed-off-by: atndko <z1281552865@gmail.com> Signed-off-by: Cyber Knight <cyberknight755@gmail.com>
Load_balancer considers only cfs running tasks for finding busiest cpu to do load balancing. But cpu may be busy with other type tasks (ex: RT), then that cpu might not selected as busy cpu due to weight vs nr_run checks fails). And possibley cfs tasks running on that cpu would suffer till other type tasks finishes or weight checks passes, while other cpus sitting idle and not able to do load balance. So, consider all running tasks to check cpu busieness. Change-Id: Iddf3f668507e20359f6388fc30ff5897d234c902 Signed-off-by: Lingutla Chandrasekhar <clingutla@codeaurora.org> Signed-off-by: atndko <z1281552865@gmail.com> Signed-off-by: Cyber Knight <cyberknight755@gmail.com>
Task stacks are frequently freed from finish_task_switch() during a context switch, in addition to the occasional task struct itself. This not only slows down context switches, but also wastes CPU time on high priority CPUs. Since unbound workqueues are now affined to the little CPU cluster, we can offload the task frees away from the current CPU entirely if it's a high-performance CPU, and defer them onto a little CPU. This reduces the amount of time spent in context switches and reclaims CPU time from more-important CPUs. Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com> Signed-off-by: Cyber Knight <cyberknight755@gmail.com>
Although mm structs are not often freed from finish_task_switch() during a context switch, they can still slow things down and waste CPU time on high priority CPUs when freed. Since unbound workqueues are now affined to the little CPU cluster, we can offload the mm struct frees away from the current CPU entirely if it's a high-performance CPU, and defer them onto a little CPU. This reduces the amount of time spent in context switches and reclaims CPU time from more-important CPUs. This is achieved without increasing the size of the mm struct by reusing the mmput async work, which is guaranteed to not be in use by the time mm_count reaches zero. Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com> Signed-off-by: Cyber Knight <cyberknight755@gmail.com>
According to RedHat, increasing this tunable reduces the number of task migrations. This should reduce time spent balancing tasks and increase per-task performance. https://www.redhat.com/files/summit/session-assets/2018/Performance-analysis-and-tuning-of-Red-Hat-Enterprise-Linux-Part-1.pdf Signed-off-by: Tyler Nijmeh <tylernij@gmail.com> Signed-off-by: Cyber Knight <cyberknight755@gmail.com>
According to a LWN article, syncookies have limited space to encode TCP handshake options, breaking large windows and selective acknowledgement. https://lwn.net/Articles/277146/ Signed-off-by: Tyler Nijmeh <tylernij@gmail.com> Signed-off-by: Cyber Knight <cyberknight755@gmail.com>
Sleepers are tasks that spend most of their time asleep. When sleepers are placed onto the runqueue, their vruntime is reduced by one full scheduling latency period so that interactive tasks are given priority over sleepers. The sched feature GENTLE_FAIR_SLEEPERS attemps to reduce the penalty given to sleeper tasks by only deducing half of a scheduling latency period, rather than a full one. This allows the sleeper to catch up in terms of vruntime with other tasks until it is preempted once again. A forked child task is not considered a sleeper task, so app launch performance will not regress. This commit should give interactive tasks more runtime while background tasks are awoken. Signed-off-by: Tyler Nijmeh <tylernij@gmail.com> Signed-off-by: Cyber Knight <cyberknight755@gmail.com>
For us, it's most helpful to have the round-robin timeslice as low as is allowed by the scheduler to reduce latency. Since it's limited by the scheduler tick rate, just set the default to 1 jiffy, which is the lowest possible value. Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com> Signed-off-by: Cyber Knight <cyberknight755@gmail.com>
Giving userspace intimate control over CPU latency requirements is nonsense. Userspace can't even stop itself from being preempted, so there's no reason for it to have access to a mechanism primarily used to eliminate CPU delays on the order of microseconds. Remove userspace's ability to send pm_qos requests so that it can't hurt power consumption. Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com> Signed-off-by: Cyber Knight <cyberknight755@gmail.com>
Currently, the kgsl worker thread is erroneously ranked right below Android's audio threads in terms of priority. The kgsl worker thread is in the critical path for rendering frames to the display, so increase its priority to match the priority of the display commit threads. Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com> Change-Id: I7d5d43bc55f708cd198dcb7d14a6d478099a6938 Signed-off-by: Cyber Knight <cyberknight755@gmail.com>
It's been observed that a panic could occur due to a race with a MSM_DRM_BLANK_POWERDOWN handler and a driver removal function upon shutdown while the screen is on. Since this shouldn't happen, send DRM events only when the system is running. This doesn't seem to be easy to detect as the events are sent after the userspace drm process terminates, which is before init binary notifies the kernel about the shutdown. Workaround this by detecting shutdown upon sysrq kill-all-tasks(i), sent from the init binary. Signed-off-by: Park Ju Hyung <qkrwngud825@gmail.com> Change-Id: I2a14d2e5ad3ce854945eed27f46dc60bf082256c Signed-off-by: Cyber Knight <cyberknight755@gmail.com>
Signed-off-by: Park Ju Hyung <qkrwngud825@gmail.com> Change-Id: Ib187c03b060a5435e2a4462c50296c7f01a4d745 Signed-off-by: Cyber Knight <cyberknight755@gmail.com>
Signed-off-by: Park Ju Hyung <qkrwngud825@gmail.com> Signed-off-by: Vaisakh Murali <mvaisakh@statixos.com> Change-Id: If18c5b1043b4ae83da05c9934f6bc1bfb2ec05a7 Signed-off-by: Cyber Knight <cyberknight755@gmail.com>
The most frequent user of fenced GMU writes, adreno_ringbuffer_submit(), performs a fenced GMU write under a spin lock, and since fenced GMU writes use udelay(), a lot of CPU cycles are burned here. Not only is the spin lock held for longer than necessary (because the write doesn't need to be inside the spin lock), but also a lot of CPU time is wasted in udelay() for tens of microseconds when usleep_range() can be used instead. Move the locked fenced GMU writes to outside their spin locks and make adreno_gmu_fenced_write() use usleep_range() when not in atomic/IRQ context, to save power and improve performance. Fenced GMU writes are found to take an average of 28 microseconds on the Snapdragon 855, so a usleep range of 10 to 30 microseconds is optimal. Note that we must still ensure that the GPU is kept alive while performing the fenced write. Also note that although the use of in_atomic() depends on PREEMPT, KGSL already uses in_interrupt() and thus already implicitly depends on PREEMPT. Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com> Change-Id: I6b3dfdad4b3986eb91401f605a0103d4dc5868a4 Signed-off-by: Cyber Knight <cyberknight755@gmail.com>
Page pool additions and removals are very hot during GPU workloads, so they should be optimized accordingly. We can use a lock-less list for storing the free pages in order to speed things up. The lock-less list allows for one llist_del_first() user and unlimited llist_add() users to run concurrently, so only a spin lock around the llist_del_first() is needed; everything else is lock-free. The per-pool page count is now an atomic to make it lock-free as well. Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com> Change-Id: I5a1b6cef1eba2172728037ff5b38a2729c9e1d3e Signed-off-by: Cyber Knight <cyberknight755@gmail.com>
KGSL already has PM QoS covering what matters. The L2PC PM QoS code is not only unneeded, but also unused, so remove it. It's poorly designed anyway since it uses a timeout with PM QoS, which is drastically bad for power consumption. Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com> Signed-off-by: Vaisakh Murali <mvaisakh@statixos.com> Change-Id: I59f2f9c2a883127825ffc0edb84f5885827336f2 Signed-off-by: Cyber Knight <cyberknight755@gmail.com>
These debug logs are everywhere and not only bloat the driver, but add latency everywhere they're used because they're not compiled out. Since they serve no purpose for us as we're not debugging SDE, compile them out. Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com> Signed-off-by: atndko <z1281552865@gmail.com> Signed-off-by: Cyber Knight <cyberknight755@gmail.com>
…oirq While executing suspend_noirq callbacks non-wakeup interrupts are disabled, wake-up interrupts are enabled but their handling is deferred till the completion of suspend_noirq stage. UART console vote/unvote the resources in suspend_noirq/resume_noirq stages. There is no issue wrt managing clk and pinctrl resources at noirq stage however ICC BW voting can't be done at noirq stage. ICC requests are converted to ack based requested for RPM driver, the ack here is nothing but interrupt from IPCC driver and it can't be processed at noirq stage, hence flow is indefinitely stuck in UART suspend_noirq callback. Change-Id: Ie279580795d3c85db4dc42766b0b2d9a8adb3f00 Signed-off-by: Akash Asthana <akashast@codeaurora.org> Signed-off-by: Andrzej Perczak <linux@andrzejperczak.com> Signed-off-by: delmontaro <jagaddhitajalu@gmail.com> Signed-off-by: Cyber Knight <cyberknight755@gmail.com>
Potential concurrent accesses to vote_clock_on/off() functions may leave runtime PM in an unwanted state. Change-Id: Ie317e8b191f5ab4083071ea55210006fb06f8079 Signed-off-by: Park Ju Hyung <qkrwngud825@gmail.com> Signed-off-by: Danny Lin <danny@kdrag0n.dev> Signed-off-by: celtare21 <celtare21@gmail.com> Signed-off-by: Yaroslav Furman <yaro330@gmail.com> Signed-off-by: Adithya R <gh0strider.2k18.reborn@gmail.com> Signed-off-by: Vaisakh Murali <mvaisakh@statixos.com> Signed-off-by: Cyber Knight <cyberknight755@gmail.com>
The time profiling here is only used to provide additional debug info for a context dump as well as a tracepoint. It adds non-trivial overhead to ringbuffer submission since it accesses GPU registers, so remove it along with the tracepoint since we're not debugging adreno. Change-Id: If52ff8fa26caa023594e71f447d0ad4fbf06e62b Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com> Signed-off-by: Vaisakh Murali <mvaisakh@statixos.com> Signed-off-by: Cyber Knight <cyberknight755@gmail.com>
Relaxing the CPU latency requirement by about 500 us won't significantly hurt graphics performance. On the flip side, most SoCs have many idle levels just below 1000 us in latency, with deeper idle levels having latencies in excess of 2000 us. Changing the latency requirement to 1000 us allows most SoCs to use their deepest sub-1000-us idle state while the GPU is active. Additionally, since the lpm driver has been updated to allow power levels with latencies equal to target latencies, change the wakeup latency from 101 to 100 for clarity. Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com> Signed-off-by: Yaroslav Furman <yaro330@gmail.com> Signed-off-by: Vaisakh Murali <mvaisakh@statixos.com> Signed-off-by: Cyber Knight <cyberknight755@gmail.com>
There's no point in enabling QoS clocks when are none of them for certain clients. Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com> Signed-off-by: Vaisakh Murali <mvaisakh@statixos.com> Signed-off-by: Cyber Knight <cyberknight755@gmail.com>
Why again calculating sched priority while it is already defined before? Change-Id: Idf089f156d3c509f625c744b1f5e4cc50a650078 Signed-off-by: Panchajanya1999 <panchajanya@azure-dev.live> (cherry picked from commit d243e7829d8614504b721a257da4e9cb49aa2399) Signed-off-by: Cyber Knight <cyberknight755@gmail.com>
[ Upstream commit ddbec99f58571301679addbc022256970ca3eac6 ] KMSAN reported the following uninit-value access issue [1]: ===================================================== BUG: KMSAN: uninit-value in hsr_get_node+0xa2e/0xa40 net/hsr/hsr_framereg.c:246 hsr_get_node+0xa2e/0xa40 net/hsr/hsr_framereg.c:246 fill_frame_info net/hsr/hsr_forward.c:577 [inline] hsr_forward_skb+0xe12/0x30e0 net/hsr/hsr_forward.c:615 hsr_dev_xmit+0x1a1/0x270 net/hsr/hsr_device.c:223 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3548 [inline] dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564 __dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349 dev_queue_xmit include/linux/netdevice.h:3134 [inline] packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3087 [inline] packet_sendmsg+0x8b1d/0x9f30 net/packet/af_packet.c:3119 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit was created at: slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768 slab_alloc_node mm/slub.c:3478 [inline] kmem_cache_alloc_node+0x5e9/0xb10 mm/slub.c:3523 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560 __alloc_skb+0x318/0x740 net/core/skbuff.c:651 alloc_skb include/linux/skbuff.h:1286 [inline] alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334 sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2787 packet_alloc_skb net/packet/af_packet.c:2936 [inline] packet_snd net/packet/af_packet.c:3030 [inline] packet_sendmsg+0x70e8/0x9f30 net/packet/af_packet.c:3119 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b CPU: 1 PID: 5033 Comm: syz-executor334 Not tainted 6.7.0-syzkaller-00562-g9f8413c4a66f #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023 ===================================================== If the packet type ID field in the Ethernet header is either ETH_P_PRP or ETH_P_HSR, but it is not followed by an HSR tag, hsr_get_skb_sequence_nr() reads an invalid value as a sequence number. This causes the above issue. This patch fixes the issue by returning NULL if the Ethernet header is not followed by an HSR tag. Fixes: f266a68 ("net/hsr: Better frame dispatch") Reported-and-tested-by: syzbot+2ef3a8ce8e91b5a50098@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=2ef3a8ce8e91b5a50098 [1] Signed-off-by: Shigeru Yoshida <syoshida@redhat.com> Link: https://lore.kernel.org/r/20240312152719.724530-1-syoshida@redhat.com Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit e3b2bfb8ff1810a537b2aa55ba906a6743ed120c) Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
[ Upstream commit 1422f28826d2a0c11e5240b3e951c9e214d8656e ] acquire/release_in_xmit() work as bit lock in rds_send_xmit(), so they are expected to ensure acquire/release memory ordering semantics. However, test_and_set_bit/clear_bit() don't imply such semantics, on top of this, following smp_mb__after_atomic() does not guarantee release ordering (memory barrier actually should be placed before clear_bit()). Instead, we use clear_bit_unlock/test_and_set_bit_lock() here. Fixes: 0f4b1c7 ("rds: fix rds_send_xmit() serialization") Fixes: 1f9ecd7 ("RDS: Pass rds_conn_path to rds_send_xmit()") Signed-off-by: Yewon Choi <woni9911@gmail.com> Reviewed-by: Michal Kubiak <michal.kubiak@intel.com> Link: https://lore.kernel.org/r/ZfQUxnNTO9AJmzwc@libra05 Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit bec6c4ce1169a565c58c347d5d0ac22e46d507d6) Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
[ Upstream commit 3cf28cd492308e5f63ed00b29ea03ca016264376 ] A failure during registration of the netdev notifier was not handled at all. A failure during netlink initialization did not unregister the netdev notifier. Handle failures of netdev notifier registration and netlink initialization. Both functions should only return negative values on failure and thereby lead to the hsr module not being loaded. Fixes: f421436 ("net/hsr: Add support for the High-availability Seamless Redundancy protocol (HSRv0)") Signed-off-by: Felix Maurer <fmaurer@redhat.com> Reviewed-by: Shigeru Yoshida <syoshida@redhat.com> Reviewed-by: Breno Leitao <leitao@debian.org> Link: https://lore.kernel.org/r/3ce097c15e3f7ace98fc7fd9bcbf299f092e63d1.1710504184.git.fmaurer@redhat.com Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 9a4e0ec0624c5b3e07fb042b307b98c3543de2f4) Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
[ Upstream commit d27e2da94a42655861ca4baea30c8cd65546f25d ]
Fix race condition leading to system crash during EEH error handling
During EEH error recovery, the bnx2x driver's transmit timeout logic
could cause a race condition when handling reset tasks. The
bnx2x_tx_timeout() schedules reset tasks via bnx2x_sp_rtnl_task(),
which ultimately leads to bnx2x_nic_unload(). In bnx2x_nic_unload()
SGEs are freed using bnx2x_free_rx_sge_range(). However, this could
overlap with the EEH driver's attempt to reset the device using
bnx2x_io_slot_reset(), which also tries to free SGEs. This race
condition can result in system crashes due to accessing freed memory
locations in bnx2x_free_rx_sge()
799 static inline void bnx2x_free_rx_sge(struct bnx2x *bp,
800 struct bnx2x_fastpath *fp, u16 index)
801 {
802 struct sw_rx_page *sw_buf = &fp->rx_page_ring[index];
803 struct page *page = sw_buf->page;
....
where sw_buf was set to NULL after the call to dma_unmap_page()
by the preceding thread.
EEH: Beginning: 'slot_reset'
PCI 0011:01:00.0#10000: EEH: Invoking bnx2x->slot_reset()
bnx2x: [bnx2x_io_slot_reset:14228(eth1)]IO slot reset initializing...
bnx2x 0011:01:00.0: enabling device (0140 -> 0142)
bnx2x: [bnx2x_io_slot_reset:14244(eth1)]IO slot reset --> driver unload
Kernel attempted to read user page (0) - exploit attempt? (uid: 0)
BUG: Kernel NULL pointer dereference on read at 0x00000000
Faulting instruction address: 0xc0080000025065fc
Oops: Kernel access of bad area, sig: 11 [#1]
.....
Call Trace:
[c000000003c67a20] [c00800000250658c] bnx2x_io_slot_reset+0x204/0x610 [bnx2x] (unreliable)
[c000000003c67af0] [c0000000000518a8] eeh_report_reset+0xb8/0xf0
[c000000003c67b60] [c000000000052130] eeh_pe_report+0x180/0x550
[c000000003c67c70] [c00000000005318c] eeh_handle_normal_event+0x84c/0xa60
[c000000003c67d50] [c000000000053a84] eeh_event_handler+0xf4/0x170
[c000000003c67da0] [c000000000194c58] kthread+0x1c8/0x1d0
[c000000003c67e10] [c00000000000cf64] ret_from_kernel_thread+0x5c/0x64
To solve this issue, we need to verify page pool allocations before
freeing.
Fixes: 4cace67 ("bnx2x: Alloc 4k fragment for each rx ring buffer element")
Signed-off-by: Thinh Tran <thinhtr@linux.ibm.com>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Link: https://lore.kernel.org/r/20240315205535.1321-1-thinhtr@linux.ibm.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit 7bcc090c81116c66936a7415f2c6b1483a4bcfd9)
Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
[ Upstream commit a20ad45008a7c82f1184dc6dee280096009ece55 ] The TX buffer in spi_transfer can be a NULL pointer, so the interrupt handler may end up writing to the invalid memory and cause crashes. Add a check to trans->tx_buf before using it. Fixes: 1ce2486 ("spi: mediatek: Only do dma for 4-byte aligned buffers") Signed-off-by: Fei Shao <fshao@chromium.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://msgid.link/r/20240321070942.1587146-2-fshao@chromium.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 2342b05ec5342a519e00524a507f7a6ea6791a38) Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
commit 662bb52f50bca16a74fe92b487a14d7dccb85e1a upstream.
Some user-space programs rely on crypto requests that have no
control metadata. This broke when a check was added to require
the presence of control metadata with the ctx->init flag.
This patch fixes the regression by setting ctx->init as long as
one sendmsg(2) has been made, with or without a control message.
Reported-by: Sachin Sant <sachinp@linux.vnet.ibm.com>
Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
Fixes: f3c802a1f300 ("crypto: algif_aead - Only wake up when...")
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 546e3961b5d4c6db82cfb441fabb4353940c8f95)
Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
commit c195d66a8a75c60515819b101975f38b7ec6577f upstream.
The iwd daemon uses libell which sets up the skcipher operation with
two separate control messages. As the first control message is sent
without MSG_MORE, it is interpreted as an empty request.
While libell should be fixed to use MSG_MORE where appropriate, this
patch works around the bug in the kernel so that existing binaries
continue to work.
We will print a warning however.
A separate issue is that the new kernel code no longer allows the
control message to be sent twice within the same request. This
restriction is obviously incompatible with what iwd was doing (first
setting an IV and then sending the real control message). This
patch changes the kernel so that this is explicitly allowed.
Reported-by: Caleb Jorden <caljorden@hotmail.com>
Fixes: f3c802a1f300 ("crypto: algif_aead - Only wake up when...")
Cc: <stable@vger.kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit ba1f292491c011fa11d80b152f15ef97e4519891)
Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
-O3 is much more stable with modern compilers these days than it was a decade ago. Using -O3 on the kernel results in significantly improved hackbench performance, which is a sign that overall performance in the kernel is improved. It works especially well in conjunction with LTO. Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com> Change-Id: I4c51599e4a8ddc1c01e301789c4a8b5794f25633
Signed-off-by: kdrag0n <dragon@khronodragon.com> Change-Id: I87faddd3bb5ca6e132ff3831bfddd2a0b4511fb9
Signed-off-by: Tyler Nijmeh <tylernij@gmail.com> Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Add native kernel support for a sane VPN Note, this disables CONFIG_ARM64_CRYPTO from the gki arm64 defconfig because CONFIG_WIREGUARD explicitly enables. So the functionality is still there, but the defconfig does not need to show it anymore. Bug: 152722841 (Picked from commit 90355457d1c9) Signed-off-by: Greg Kroah-Hartman <gregkh@google.com> Change-Id: Iece00c78770ac146d0f5bc252902794fec2e3955
There's plenty of room on the stack for a few more inlined bytes here and there. The measured stack usage at runtime is still safe without this, and performance is surely improved at a microscopic level, so remove it. Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>
karthick111
pushed a commit
that referenced
this pull request
Jun 20, 2024
[ Upstream commit a154f5f643c6ecddd44847217a7a3845b4350003 ] The following call trace shows a deadlock issue due to recursive locking of mutex "device_mutex". First lock acquire is in target_for_each_device() and second in target_free_device(). PID: 148266 TASK: ffff8be21ffb5d00 CPU: 10 COMMAND: "iscsi_ttx" #0 [ffffa2bfc9ec3b18] __schedule at ffffffffa8060e7f #1 [ffffa2bfc9ec3ba0] schedule at ffffffffa8061224 #2 [ffffa2bfc9ec3bb8] schedule_preempt_disabled at ffffffffa80615ee #3 [ffffa2bfc9ec3bc8] __mutex_lock at ffffffffa8062fd7 #4 [ffffa2bfc9ec3c40] __mutex_lock_slowpath at ffffffffa80631d3 #5 [ffffa2bfc9ec3c50] mutex_lock at ffffffffa806320c #6 [ffffa2bfc9ec3c68] target_free_device at ffffffffc0935998 [target_core_mod] #7 [ffffa2bfc9ec3c90] target_core_dev_release at ffffffffc092f975 [target_core_mod] #8 [ffffa2bfc9ec3ca0] config_item_put at ffffffffa79d250f #9 [ffffa2bfc9ec3cd0] config_item_put at ffffffffa79d2583 #10 [ffffa2bfc9ec3ce0] target_devices_idr_iter at ffffffffc0933f3a [target_core_mod] #11 [ffffa2bfc9ec3d00] idr_for_each at ffffffffa803f6fc #12 [ffffa2bfc9ec3d60] target_for_each_device at ffffffffc0935670 [target_core_mod] #13 [ffffa2bfc9ec3d98] transport_deregister_session at ffffffffc0946408 [target_core_mod] #14 [ffffa2bfc9ec3dc8] iscsit_close_session at ffffffffc09a44a6 [iscsi_target_mod] #15 [ffffa2bfc9ec3df0] iscsit_close_connection at ffffffffc09a4a88 [iscsi_target_mod] #16 [ffffa2bfc9ec3df8] finish_task_switch at ffffffffa76e5d07 #17 [ffffa2bfc9ec3e78] iscsit_take_action_for_connection_exit at ffffffffc0991c23 [iscsi_target_mod] #18 [ffffa2bfc9ec3ea0] iscsi_target_tx_thread at ffffffffc09a403b [iscsi_target_mod] #19 [ffffa2bfc9ec3f08] kthread at ffffffffa76d8080 #20 [ffffa2bfc9ec3f50] ret_from_fork at ffffffffa8200364 Fixes: 36d4cb460bcb ("scsi: target: Avoid that EXTENDED COPY commands trigger lock inversion") Signed-off-by: Junxiao Bi <junxiao.bi@oracle.com> Link: https://lore.kernel.org/r/20230918225848.66463-1-junxiao.bi@oracle.com Reviewed-by: Mike Christie <michael.christie@oracle.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
karthick111
pushed a commit
that referenced
this pull request
Jun 20, 2024
commit 5a22fbcc10f3f7d94c5d88afbbffa240a3677057 upstream.
When LAN9303 is MDIO-connected two callchains exist into
mdio->bus->write():
1. switch ports 1&2 ("physical" PHYs):
virtual (switch-internal) MDIO bus (lan9303_switch_ops->phy_{read|write})->
lan9303_mdio_phy_{read|write} -> mdiobus_{read|write}_nested
2. LAN9303 virtual PHY:
virtual MDIO bus (lan9303_phy_{read|write}) ->
lan9303_virt_phy_reg_{read|write} -> regmap -> lan9303_mdio_{read|write}
If the latter functions just take
mutex_lock(&sw_dev->device->bus->mdio_lock) it triggers a LOCKDEP
false-positive splat. It's false-positive because the first
mdio_lock in the second callchain above belongs to virtual MDIO bus, the
second mdio_lock belongs to physical MDIO bus.
Consequent annotation in lan9303_mdio_{read|write} as nested lock
(similar to lan9303_mdio_phy_{read|write}, it's the same physical MDIO bus)
prevents the following splat:
WARNING: possible circular locking dependency detected
5.15.71 #1 Not tainted
------------------------------------------------------
kworker/u4:3/609 is trying to acquire lock:
ffff000011531c68 (lan9303_mdio:131:(&lan9303_mdio_regmap_config)->lock){+.+.}-{3:3}, at: regmap_lock_mutex
but task is already holding lock:
ffff0000114c44d8 (&bus->mdio_lock){+.+.}-{3:3}, at: mdiobus_read
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&bus->mdio_lock){+.+.}-{3:3}:
lock_acquire
__mutex_lock
mutex_lock_nested
lan9303_mdio_read
_regmap_read
regmap_read
lan9303_probe
lan9303_mdio_probe
mdio_probe
really_probe
__driver_probe_device
driver_probe_device
__device_attach_driver
bus_for_each_drv
__device_attach
device_initial_probe
bus_probe_device
deferred_probe_work_func
process_one_work
worker_thread
kthread
ret_from_fork
-> #0 (lan9303_mdio:131:(&lan9303_mdio_regmap_config)->lock){+.+.}-{3:3}:
__lock_acquire
lock_acquire.part.0
lock_acquire
__mutex_lock
mutex_lock_nested
regmap_lock_mutex
regmap_read
lan9303_phy_read
dsa_slave_phy_read
__mdiobus_read
mdiobus_read
get_phy_device
mdiobus_scan
__mdiobus_register
dsa_register_switch
lan9303_probe
lan9303_mdio_probe
mdio_probe
really_probe
__driver_probe_device
driver_probe_device
__device_attach_driver
bus_for_each_drv
__device_attach
device_initial_probe
bus_probe_device
deferred_probe_work_func
process_one_work
worker_thread
kthread
ret_from_fork
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&bus->mdio_lock);
lock(lan9303_mdio:131:(&lan9303_mdio_regmap_config)->lock);
lock(&bus->mdio_lock);
lock(lan9303_mdio:131:(&lan9303_mdio_regmap_config)->lock);
*** DEADLOCK ***
5 locks held by kworker/u4:3/609:
#0: ffff000002842938 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work
#1: ffff80000bacbd60 (deferred_probe_work){+.+.}-{0:0}, at: process_one_work
#2: ffff000007645178 (&dev->mutex){....}-{3:3}, at: __device_attach
#3: ffff8000096e6e78 (dsa2_mutex){+.+.}-{3:3}, at: dsa_register_switch
#4: ffff0000114c44d8 (&bus->mdio_lock){+.+.}-{3:3}, at: mdiobus_read
stack backtrace:
CPU: 1 PID: 609 Comm: kworker/u4:3 Not tainted 5.15.71 #1
Workqueue: events_unbound deferred_probe_work_func
Call trace:
dump_backtrace
show_stack
dump_stack_lvl
dump_stack
print_circular_bug
check_noncircular
__lock_acquire
lock_acquire.part.0
lock_acquire
__mutex_lock
mutex_lock_nested
regmap_lock_mutex
regmap_read
lan9303_phy_read
dsa_slave_phy_read
__mdiobus_read
mdiobus_read
get_phy_device
mdiobus_scan
__mdiobus_register
dsa_register_switch
lan9303_probe
lan9303_mdio_probe
...
Cc: stable@vger.kernel.org
Fixes: dc70058 ("net: dsa: LAN9303: add MDIO managed mode support")
Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://lore.kernel.org/r/20231027065741.534971-1-alexander.sverdlin@siemens.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
karthick111
pushed a commit
that referenced
this pull request
Jun 21, 2024
[ Upstream commit 14694179e561b5f2f7e56a0f590e2cb49a9cc7ab ]
Trying to suspend to RAM on SAMA5D27 EVK leads to the following lockdep
warning:
============================================
WARNING: possible recursive locking detected
6.7.0-rc5-wt+ #532 Not tainted
--------------------------------------------
sh/92 is trying to acquire lock:
c3cf306c (&irq_desc_lock_class){-.-.}-{2:2}, at: __irq_get_desc_lock+0xe8/0x100
but task is already holding lock:
c3d7c46c (&irq_desc_lock_class){-.-.}-{2:2}, at: __irq_get_desc_lock+0xe8/0x100
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&irq_desc_lock_class);
lock(&irq_desc_lock_class);
*** DEADLOCK ***
May be due to missing lock nesting notation
6 locks held by sh/92:
#0: c3aa0258 (sb_writers#6){.+.+}-{0:0}, at: ksys_write+0xd8/0x178
#1: c4c2df44 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x138/0x284
#2: c32684a0 (kn->active){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x148/0x284
#3: c232b6d4 (system_transition_mutex){+.+.}-{3:3}, at: pm_suspend+0x13c/0x4e8
#4: c387b088 (&dev->mutex){....}-{3:3}, at: __device_suspend+0x1e8/0x91c
#5: c3d7c46c (&irq_desc_lock_class){-.-.}-{2:2}, at: __irq_get_desc_lock+0xe8/0x100
stack backtrace:
CPU: 0 PID: 92 Comm: sh Not tainted 6.7.0-rc5-wt+ #532
Hardware name: Atmel SAMA5
unwind_backtrace from show_stack+0x18/0x1c
show_stack from dump_stack_lvl+0x34/0x48
dump_stack_lvl from __lock_acquire+0x19ec/0x3a0c
__lock_acquire from lock_acquire.part.0+0x124/0x2d0
lock_acquire.part.0 from _raw_spin_lock_irqsave+0x5c/0x78
_raw_spin_lock_irqsave from __irq_get_desc_lock+0xe8/0x100
__irq_get_desc_lock from irq_set_irq_wake+0xa8/0x204
irq_set_irq_wake from atmel_gpio_irq_set_wake+0x58/0xb4
atmel_gpio_irq_set_wake from irq_set_irq_wake+0x100/0x204
irq_set_irq_wake from gpio_keys_suspend+0xec/0x2b8
gpio_keys_suspend from dpm_run_callback+0xe4/0x248
dpm_run_callback from __device_suspend+0x234/0x91c
__device_suspend from dpm_suspend+0x224/0x43c
dpm_suspend from dpm_suspend_start+0x9c/0xa8
dpm_suspend_start from suspend_devices_and_enter+0x1e0/0xa84
suspend_devices_and_enter from pm_suspend+0x460/0x4e8
pm_suspend from state_store+0x78/0xe4
state_store from kernfs_fop_write_iter+0x1a0/0x284
kernfs_fop_write_iter from vfs_write+0x38c/0x6f4
vfs_write from ksys_write+0xd8/0x178
ksys_write from ret_fast_syscall+0x0/0x1c
Exception stack(0xc52b3fa8 to 0xc52b3ff0)
3fa0: 00000004 005a0ae8 00000001 005a0ae8 00000004 00000001
3fc0: 00000004 005a0ae8 00000001 00000004 00000004 b6c616c0 00000020 0059d190
3fe0: 00000004 b6c61678 aec5a041 aebf1a26
This warning is raised because pinctrl-at91-pio4 uses chained IRQ. Whenever
a wake up source configures an IRQ through irq_set_irq_wake, it will
lock the corresponding IRQ desc, and then call irq_set_irq_wake on "parent"
IRQ which will do the same on its own IRQ desc, but since those two locks
share the same class, lockdep reports this as an issue.
Fix lockdep false positive by setting a different class for parent and
children IRQ
Fixes: 7761808 ("pinctrl: introduce driver for Atmel PIO4 controller")
Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Link: https://lore.kernel.org/r/20231215-lockdep_warning-v1-1-8137b2510ed5@bootlin.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
karthick111
pushed a commit
that referenced
this pull request
Jun 21, 2024
[ Upstream commit f8bbc07ac535593139c875ffa19af924b1084540 ] vhost_worker will call tun call backs to receive packets. If too many illegal packets arrives, tun_do_read will keep dumping packet contents. When console is enabled, it will costs much more cpu time to dump packet and soft lockup will be detected. net_ratelimit mechanism can be used to limit the dumping rate. PID: 33036 TASK: ffff949da6f20000 CPU: 23 COMMAND: "vhost-32980" #0 [fffffe00003fce50] crash_nmi_callback at ffffffff89249253 #1 [fffffe00003fce58] nmi_handle at ffffffff89225fa3 #2 [fffffe00003fceb0] default_do_nmi at ffffffff8922642e #3 [fffffe00003fced0] do_nmi at ffffffff8922660d #4 [fffffe00003fcef0] end_repeat_nmi at ffffffff89c01663 [exception RIP: io_serial_in+20] RIP: ffffffff89792594 RSP: ffffa655314979e8 RFLAGS: 00000002 RAX: ffffffff89792500 RBX: ffffffff8af428a0 RCX: 0000000000000000 RDX: 00000000000003fd RSI: 0000000000000005 RDI: ffffffff8af428a0 RBP: 0000000000002710 R8: 0000000000000004 R9: 000000000000000f R10: 0000000000000000 R11: ffffffff8acbf64f R12: 0000000000000020 R13: ffffffff8acbf698 R14: 0000000000000058 R15: 0000000000000000 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #5 [ffffa655314979e8] io_serial_in at ffffffff89792594 #6 [ffffa655314979e8] wait_for_xmitr at ffffffff89793470 #7 [ffffa65531497a08] serial8250_console_putchar at ffffffff897934f6 #8 [ffffa65531497a20] uart_console_write at ffffffff8978b605 #9 [ffffa65531497a48] serial8250_console_write at ffffffff89796558 #10 [ffffa65531497ac8] console_unlock at ffffffff89316124 #11 [ffffa65531497b10] vprintk_emit at ffffffff89317c07 #12 [ffffa65531497b68] printk at ffffffff89318306 #13 [ffffa65531497bc8] print_hex_dump at ffffffff89650765 #14 [ffffa65531497ca8] tun_do_read at ffffffffc0b06c27 [tun] #15 [ffffa65531497d38] tun_recvmsg at ffffffffc0b06e34 [tun] #16 [ffffa65531497d68] handle_rx at ffffffffc0c5d682 [vhost_net] #17 [ffffa65531497ed0] vhost_worker at ffffffffc0c644dc [vhost] #18 [ffffa65531497f10] kthread at ffffffff892d2e72 #19 [ffffa65531497f50] ret_from_fork at ffffffff89c0022f Fixes: ef3db4a ("tun: avoid BUG, dump packet on GSO errors") Signed-off-by: Lei Chen <lei.chen@smartx.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Acked-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Link: https://lore.kernel.org/r/20240415020247.2207781-1-lei.chen@smartx.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 68459b8e3ee554ce71878af9eb69659b9462c588) Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
accept pull