Add initial symbol list for rockchip in android/abi_gki_aarch64_rockchip
Bug: 300024866
Change-Id: I4fd44b33141dfbdcd5b8d0d7c5d0fbc5aa2758cc
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Commit 95158a89dd ("sched,rt: Use the full cpumask for balancing")
allows find_lock_lowest_rq() to pick a task with migration disabled.
The purpose of the commit is to push the current running task on the
CPU that has the migrate_disable() task away.
However, there is a race which allows a migrate_disable() task to be
migrated. Consider:
CPU0 CPU1
push_rt_task
check is_migration_disabled(next_task)
task not running and
migration_disabled == 0
find_lock_lowest_rq(next_task, rq);
_double_lock_balance(this_rq, busiest);
raw_spin_rq_unlock(this_rq);
double_rq_lock(this_rq, busiest);
<<wait for busiest rq>>
<wakeup>
task become running
migrate_disable();
<context out>
deactivate_task(rq, next_task, 0);
set_task_cpu(next_task, lowest_rq->cpu);
WARN_ON_ONCE(is_migration_disabled(p));
Fixes: 95158a89dd ("sched,rt: Use the full cpumask for balancing")
Signed-off-by: Schspa Shi <schspa@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Reviewed-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
Reviewed-by: Valentin Schneider <vschneid@redhat.com>
Tested-by: Dwaine Gonyier <dgonyier@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Bug: 300418678
(cherry picked from commit feffe5bb27)
[quic_dickey@quicinc.com: Port only]
Change-Id: I3e7953aeb3edf3f1a5d03e355297d7b1541ff7c8
Signed-off-by: Stephen Dickey <quic_dickey@quicinc.com>
create the ASUS symbol list of HID symbols for the USB HID Fan driver which requires them
6 function symbol(s) added
'int __hid_register_driver(struct hid_driver*, struct module*, const char*)'
'int hid_hw_raw_request(struct hid_device*, unsigned char, __u8*, size_t, enum hid_report_type, enum hid_class_request)'
'int hid_hw_start(struct hid_device*, unsigned int)'
'void hid_hw_stop(struct hid_device*)'
'int hid_open_report(struct hid_device*)'
'void hid_unregister_driver(struct hid_driver*)'
Bug: 300220786
Change-Id: I422c3b82754921c530e9afc32529a1dbf2f6c38e
Signed-off-by: Steve2 Yang <steve2_yang@asus.com>
Update whitelist for the symbols used by the unisoc device and
update the ABI representation accordingly.
1 function symbol(s) added
'int pvclock_gtod_register_notifier(struct notifier_block*)'
Bug: 300019103
Change-Id: Ice320a418069f24a27d14939a143ce01f50c0de8
Signed-off-by: Enlin Mu <enlin.mu@unisoc.com>
Add vendor hook to determine if the memory of a process
that received the SIGKILL can be reaped.
Partial cherry-pick of aosp/1724512 & aosp/2093626.
Bug: 232062955
Change-Id: I75072bd264df33caff67d083821ee6f33ca83af9
Signed-off-by: Tangquan Zheng <zhengtangquan@oppo.com>
Whitelist the below symbols that can be used to decide if overshooting
of kswapd reclaim is allowed.
Symbols added:
__traceiter_android_vh_scan_abort_check_wmarks
__tracepoint_android_vh_scan_abort_check_wmarks
Bug: 224956008
Change-Id: I185a570b345d2db0a1426075faa4d9c6325fb0e8
Signed-off-by: Charan Teja Kalla <quic_charante@quicinc.com>
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
Allow vendor hook to enable checking of the high water marks to
decide if reclaim should continue scanning.
Bug: 224956008
Change-Id: I63fe1fd386e7599451c2df0a04c8440b4fc142fc
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
When ufshcd_clk_scaling_suspend_work(Thread A) running and new command
coming, ufshcd_clk_scaling_start_busy(Thread B) may get host_lock
after Thread A first time release host_lock. Then Thread A second time
get host_lock will set clk_scaling.window_start_t = 0 which scale up
clock abnormal next polling_ms time.
Also inlines another __ufshcd_suspend_clkscaling calls.
Below is racing step:
1 hba->clk_scaling.suspend_work (Thread A)
ufshcd_clk_scaling_suspend_work
2 spin_lock_irqsave(hba->host->host_lock, irq_flags);
3 hba->clk_scaling.is_suspended = true;
4 spin_unlock_irqrestore(hba->host->host_lock, irq_flags);
__ufshcd_suspend_clkscaling
7 spin_lock_irqsave(hba->host->host_lock, flags);
8 hba->clk_scaling.window_start_t = 0;
9 spin_unlock_irqrestore(hba->host->host_lock, flags);
ufshcd_send_command (Thread B)
ufshcd_clk_scaling_start_busy
5 spin_lock_irqsave(hba->host->host_lock, flags);
....
6 spin_unlock_irqrestore(hba->host->host_lock, flags);
Bug: 298004596
Link: https://lore.kernel.org/all/20230831130826.5592-3-peter.wang@mediatek.com/
Change-Id: Ib208b1265107769005c4ae3f72d46b12c072b5c7
Signed-off-by: Peter Wang <peter.wang@mediatek.com>
When no active_reqs, devfreq_monitor(Thread A) will suspend clock scaling.
But it may have racing with clk_scaling.suspend_work(Thread B) and
actually not suspend clock scaling(requue after suspend).
Next time after polling_ms, devfreq_monitor read
clk_scaling.window_start_t = 0 then scale up clock abnormal.
Below is racing step:
devfreq->work (Thread A)
devfreq_monitor
update_devfreq
.....
ufshcd_devfreq_target
queue_work(hba->clk_scaling.workq,
1 &hba->clk_scaling.suspend_work)
.....
5 queue_delayed_work(devfreq_wq, &devfreq->work,
msecs_to_jiffies(devfreq->profile->polling_ms));
2 hba->clk_scaling.suspend_work (Thread B)
ufshcd_clk_scaling_suspend_work
__ufshcd_suspend_clkscaling
devfreq_suspend_device(hba->devfreq);
3 cancel_delayed_work_sync(&devfreq->work);
4 hba->clk_scaling.window_start_t = 0;
.....
Bug: 298004596
Link: https://lore.kernel.org/all/20230831130826.5592-4-peter.wang@mediatek.com/
Change-Id: I3ea77255f1b3845e9dd7bf6b050f3e9ba1f5f3f2
Signed-off-by: Peter Wang <peter.wang@mediatek.com>
Regenerate ABU definition file to resolve ABI breakage caused by a
private struct zs_pool:
INFO: ABI DIFFERENCES HAVE BEEN DETECTED!
INFO: type 'struct zs_pool' changed
member 'atomic_t compaction_in_progress' was added
Bug: 296365608
Change-Id: I477b6dbbdaf464b2fdf3e666b9696f1a79095a63
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
zsmalloc pool can be compacted concurrently by many contexts,
e.g.
cc1 handle_mm_fault()
do_anonymous_page()
__alloc_pages_slowpath()
try_to_free_pages()
do_try_to_free_pages(
lru_gen_shrink_node()
shrink_slab()
do_shrink_slab()
zs_shrinker_scan()
zs_compact()
Pool compaction is currently (basically) single-threaded as
it is performed under pool->lock. Having multiple compaction
threads results in unnecessary contention, as each thread
competes for pool->lock. This, in turn, affects all zsmalloc
operations such as zs_malloc(), zs_map_object(), zs_free(), etc.
Introduce the pool->compaction_in_progress atomic variable,
which ensures that only one compaction context can run at a
time. This reduces overall pool->lock contention in (corner)
cases when many contexts attempt to shrink zspool simultaneously.
Link: https://lkml.kernel.org/r/20230418074639.1903197-1-senozhatsky@chromium.org
Fixes: c0547d0b6a ("zsmalloc: consolidate zs_pool's migrate_lock and size_class's locks")
Signed-off-by: Sergey Senozhatsky <senozhatsky@chromium.org>
Reviewed-by: Yosry Ahmed <yosryahmed@google.com>
Cc: Minchan Kim <minchan@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
(cherry picked from commit cb440cecb2)
Bug: 296365608
Change-Id: Ic7878e08c3484ade8c766d051a8f17cc8179eedf
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Update whitelist for the symbols used by qcom socs in
abi_gki_aarch64_qcom.
1 function symbol(s) added
'vhost_dev_flush'
Bug: 299585715
Change-Id: I403394331953c9cfee54b4b0c2a0365a3df5f0af
Signed-off-by: Prathu Baronia <quic_pbaronia@quicinc.com>
Signed-off-by: Aleksei Vetrov <vvvvvv@google.com>
When sending Discover Identity messages to a Port Partner that uses Power
Delivery v2 and SVDM v1, we currently send PD v2 messages with SVDM v2.0,
expecting the port partner to respond with its highest supported SVDM
version as stated in Section 6.4.4.2.3 in the Power Delivery v3
specification. However, sending SVDM v2 to some Power Delivery v2 port
partners results in a NAK whereas sending SVDM v1 does not.
NAK messages can be handled by the initiator (PD v3 section 6.4.4.2.5.1),
and one solution could be to resend Discover Identity on a lower SVDM
version if possible. But, Section 6.4.4.3 of PD v2 states that "A NAK
response Should be taken as an indication not to retry that particular
Command."
Instead, we can set the SVDM version to the maximum one supported by the
negotiated PD revision. When operating in PD v2, this obeys Section
6.4.4.2.3, which states the SVDM field "Shall be set to zero to indicate
Version 1.0." In PD v3, the SVDM field "Shall be set to 01b to indicate
Version 2.0."
Fixes: c34e85fa69 ("usb: typec: tcpm: Send DISCOVER_IDENTITY from dedicated work")
Cc: stable@vger.kernel.org
Signed-off-by: RD Babiera <rdbabiera@google.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20230731165926.1815338-1-rdbabiera@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 289437937
(cherry picked from commit c97cd0b4b5)
Signed-off-by: RD Babiera <rdbabiera@google.com>
(cherry picked from https://android-review.googlesource.com/q/commit:d02aef1ae51a03b9ab20c8e01ed32593a7ffc6fc)
Merged-In: Ie919c29bab68cb08cb659471ff6106bae502c8dd
Change-Id: Ie919c29bab68cb08cb659471ff6106bae502c8dd
Share/unshare initiated by host doesn't change memory permission, and
as currently pKVM doesn't support device assignment, there is no need
to update the IOMMU unnecessarily as it waste cycles.
Once device assignment is enabled, this assumption will not be valid
as guests have access to DMA.
Bug: 291843613
Change-Id: I28c69ec8f721711d5b59fa2784386fa61654fe5a
Signed-off-by: Mostafa Saleh <smostafa@google.com>
There are some corner cases where we do worse in power because the
threshold is too low. Until these cases are better understood and
addressed upstream, provide a function for vendors to override this
value with something more suitable in their modules.
Bug: 289293494
Signed-off-by: Qais Yousef <qyousef@google.com>
Change-Id: I95dd36718a317f3fcb2a9f4bc87dd3390a4f7d7d
Vendor may have need to track rt util.
Bug: 201261299
Signed-off-by: Rick Yiu <rickyiu@google.com>
Change-Id: I2f4e5142c6bc8574ee3558042e1fb0dae13b702d
Vendor may have the need to implement their own util tracking.
Bug: 297343949
Signed-off-by: Rick Yiu <rickyiu@google.com>
Change-Id: I973902e6ff82a85ecd029ac5a78692d629df1ebe
Upstream moved the sugov to DEADLINE class which has higher prio than RT
so it can potentially block many RT use case in Android.
Also currently iowait doesn't distinguish background/foreground tasks
and we have seen cases where device run to high frequency unnecessarily
when running some background I/O.
Bug: 297343949
Signed-off-by: Wei Wang <wvw@google.com>
Change-Id: I21e9bfe9ef75a4178279574389e417c3f38e65ac
We want to add more special values, specifically for uclamp_max so that
it can be set automatically to the most efficient value based on the
core it's running on.
Bug: 297343949
Signed-off-by: Qais Yousef <qyousef@google.com>
Change-Id: I57343c4544f6cac621c855cbb94de0b8d80c51fa
Vendors could decide to use amu fie feature or not, such as if they
have some feature that needs amu fie to be disabled.
Bug: 297343949
Change-Id: I6b44ee899c58e7d5a8b2db03a30e3ab14b08f101
Signed-off-by: Rick Yiu <rickyiu@google.com>
Update symbol list for Exynos Auto SoCs
Bug: 299219798
Signed-off-by: Bumyong Lee <bumyong.lee@samsung.com>
Change-Id: I2a6a58cdfceb28186ee6a5778ce78e872d06c04f
[ Upstream commit 90e5b3462e ]
When flushing, individual set elements are disabled in the next
generation via the ->flush callback.
Catchall elements are not disabled. This is incorrect and may lead to
double-deactivations of catchall elements which then results in memory
leaks:
WARNING: CPU: 1 PID: 3300 at include/net/netfilter/nf_tables.h:1172 nft_map_deactivate+0x549/0x730
CPU: 1 PID: 3300 Comm: nft Not tainted 6.5.0-rc5+ #60
RIP: 0010:nft_map_deactivate+0x549/0x730
[..]
? nft_map_deactivate+0x549/0x730
nf_tables_delset+0xb66/0xeb0
(the warn is due to nft_use_dec() detecting underflow).
Bug: 298710879
Fixes: aaa31047a6 ("netfilter: nftables: add catch-all set element support")
Reported-by: lonial con <kongln9170@gmail.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit 00ea7eb1c6)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I870613042789da3ab44f5f34a240f5dc8c4b25a2
step 1: export the follow symbols in file net/core/net-trace.c
EXPORT_TRACEPOINT_SYMBOL_GPL(net_dev_queue);
EXPORT_TRACEPOINT_SYMBOL_GPL(net_dev_xmit);
EXPORT_TRACEPOINT_SYMBOL_GPL(netif_receive_skb);
EXPORT_TRACEPOINT_SYMBOL_GPL(netif_rx);
step 2: update to symbol list, see link:
https://android-review.googlesource.com/c/kernel/common/+/2742633
Bug: 193384408
Change-Id: I5a247d04000289809db89b609ddaec9af33db041
Signed-off-by: Wei Liu <liuwei.a@oppo.com>
Recursive spin_lock/unlock_irq() is not safe, because spin_unlock_irq()
will enable irq unconditionally:
spin_lock_irq queue_lock -> disable irq
spin_lock_irq ioc->lock
spin_unlock_irq ioc->lock -> enable irq
/*
* AA dead lock will be triggered if current context is preempted by irq,
* and irq try to hold queue_lock again.
*/
spin_unlock_irq queue_lock
Fix this problem by using spin_lock/unlock() directly for 'ioc->lock'.
Fixes: 5a0ac57c48 ("blk-ioc: protect ioc_destroy_icq() by 'queue_lock'")
Signed-off-by: Yu Kuai <yukuai3@huawei.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Link: https://lore.kernel.org/r/20230606011438.3743440-1-yukuai1@huaweicloud.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Bug: 285274586
(cherry picked from commit a7cfa0af0c)
Change-Id: I92433b1c639d20dd0cab6fc495a1b087cfdc8835
Signed-off-by: Pradeep P V K <quic_pragalla@quicinc.com>
BPF is always 64-bit code, so we need to pad the uapi structs to be the
same on 32-bit as 64-bit
Bug: 285477572
Test: Cuttlefish x86_64, x86 and x86 only all boot and load fuseMedia
Change-Id: Idf5b09b2581b8d097048e7d2ff4039cd1806c082
Signed-off-by: Paul Lawrence <paullawrence@google.com>
When the task wakes up from percpu_rwsem_wait, it will enter a long
runnable state, which will cause frame loss when the application
starts. In order to solve this problem, we need to let the process
enter the "vip" queue when it is woken up, so we need to set a flag
for the process holding the lock to prove that it is about to hold
the lock. Most of this long runnable state occurs in the
cgroup_threadgroup_rwsem, so we only care cgroup_threadgroup_rwsem,
and cgroup_threadgroup_rwsem should be exported. Finally, if the
semaphore is of cgroup_threadgroup_rwsem type and has a flag,
then let it join the "vip" queue.
Bug: 297785167
Signed-off-by: liuxudong <liuxudong5@xiaomi.com>
Change-Id: I2297dfbc2f2681581241f85a3b4fd59415ea67db
We were getting the inode with the parent inode info
Also change variable names to remove confusion
Also set bpf correctly in new inode
Bug: 293838958
Test: fuse_test, atest ScopedStorageDeviceTest,
atest CtsScopedStorageHostTest
Change-Id: I0b6a6951599e0d211afd2243daacb98679503448
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Currently, icq is tracked by both request_queue(icq->q_node) and
task(icq->ioc_node), and ioc_clear_queue() from elevator exit is not
safe because it can access the list without protection:
ioc_clear_queue ioc_release_fn
lock queue_lock
list_splice
/* move queue list to a local list */
unlock queue_lock
/*
* lock is released, the local list
* can be accessed through task exit.
*/
lock ioc->lock
while (!hlist_empty)
icq = hlist_entry
lock queue_lock
ioc_destroy_icq
delete icq->ioc_node
while (!list_empty)
icq = list_entry() list_del icq->q_node
/*
* This is not protected by any lock,
* list_entry concurrent with list_del
* is not safe.
*/
unlock queue_lock
unlock ioc->lock
Fix this problem by protecting list 'icq->q_node' by queue_lock from
ioc_clear_queue().
Reported-and-tested-by: Pradeep Pragallapati <quic_pragalla@quicinc.com>
Link: https://lore.kernel.org/lkml/20230517084434.18932-1-quic_pragalla@quicinc.com/
Signed-off-by: Yu Kuai <yukuai3@huawei.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Link: https://lore.kernel.org/r/20230531073435.2923422-1-yukuai1@huaweicloud.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Bug: 285274586
(cherry picked from commit 5a0ac57c48)
Change-Id: I60f3acfaa32f18bed58c8190178cdca5ebd91100
Signed-off-by: Pradeep P V K <quic_pragalla@quicinc.com>
